The example is bug#254511
From the user's perspective once he files an issue with (or without) a patch attached somebody from the system should look into it and respond.
System auto-assigned it to "Nobody" and nothing is happening for days.
So what is the mechanism of FreeBSD reacting to such issues?
Each category should have somebody attached who could look at the issue and at least make a determination for: (1) priority (2) the right person who can address it.
(In reply to Yuri Victorovich from comment #0)
> System auto-assigned it to "Nobody" and nothing is happening for days.
The actual mailing list assignment is "freebsd-bugs@" which is the default assignee. The "Nobody" is simply an annotation that the assignment is not specific to one person.
> So what is the mechanism of FreeBSD reacting to such issues?
It is the same as anything else: all done on a volunteer basis.
We have many people who do triage work to try to quickly assign issues to (at least) the relevant mailing lists. But that is not the same as having people standing by to analyze the content.
I honestly do know what Bugmeister can be asked to do here.
The 'new' state is for untriaged issues. It is the first state issues are in on creation. Anything "New" hasn't been triaged. This is course doesn't capture when people respond on an issue but don't change the state to Open.
If there's a good (better, well defined, searchable) definition of 'untriaged', we can create shared searched for untriaged issues for each repo.
We've thought of 'saved searches' for 'need triage' that are defined as more than just status:new for a long time, but its non-trivial to define the conditions. Is it when somebody comments? Is it when there's no comments? Is it when last mod time == create time? Some other combination of attributes?
Note also, we have a saved search (which is in the footer for every user) called Ports: Needs Triage, which is defined as status:new assignee:default (ports-bugs, aka unassigned).
Bugzilla also has the notion of an UNCONFIRMED issue, but we'd be hesitant to 'add' more things to the process, than better tool or use the existing process
Further, the fact that base system (src) has no strict, extensive or well defined notion of maintainer(s), unlike ports (MAINTAINER lines), makes the challenge more difficult.
This can be partly ameliorated by more components, which can have distinct default assignees and cc lists, but this is also adds a manual management and stale-once-created consideration.