If the bug submitters feel their submissions are just going into the bit bucket in the sky, then the submissions will stop.
There needs to be some positive feedback for someone to take the time out of their day to create the report. A perfectly reasonable outcome are decisions like "This is on the roadmap for 1.5" and "This fix can wait until 1.4". Hank On Thu, Mar 29, 2012 at 6:54 AM, Ruediger Rolf <[email protected]>wrote: > Hi Hank, > > I am -1 to this proposal. > > I guess that these tickets will then only be assigned to developers that > come to the dev meetings frequently. We would maybe prevent devs from > coming to the meeting. The next point was like in fixing bugs for 1.3 if a > ticket is assigned it typically means that this issue should adressed soon. > Some of the unassigned tickets are not very important or from my point of > view feature requests instead of bugs. If a ticket is assigned no other > developer with free cycles (if something like this really exists) might > take it. So I share Tobias concerns. > > We should create public filters that any developer should check frequently. > > The QA and the RMs should address tickets that they think are important to > be solved very quickly and assign they to dev who can solve them and who is > available. > > Rüdiger > > Am 28.03.2012 21:35, schrieb Tobias Wunden: > >> Hank, >> >> I like this proposal as well. However, I would suggest automatically >> assigning new tickets to a special component rather than a person, since as >> long as it's assigned to a person, nothing will happen if that person is on >> holidays, busy with "local issues" etc. >> >> Tobias >> >> On 28.03.2012, at 20:49, Hank Magnuski<[email protected]> wrote: >> >> As a somewhat prolific bug submitter I find it disappointing that (as of >>> today) 12 of my 21 open issues are still "unassigned". >>> >>> Makes one feel like no one is minding the store. >>> >>> I think all submitted bugs should be assigned to someone at the weekly >>> developers meeting. At least there will be an internal owner of the problem >>> even though there may be no immediate resource available to fix it. >>> >>> For a new adopter knowing that there is a developer owner for the >>> problem would at least be comforting. >>> >>> Hank >>> >>>
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
