I'll reiterate one thing that came up at meeting yesterday: to avoid that feeling of things "going into the bit bucket in the sky" there should be a requirement on the part of those downgrading, pushing out to another release, or closing tickets (as other than "fixed") to explain their actions.
I think open ticket review at meetings is a good idea. Furthermore, I wonder if it's reasonable to agree on a policy that any ticket that's "Critical" or "Blocker" (maybe "Major", too) will be reviewed by a pre-designated human (a component "lead" perhaps) who has agreed to be responsible for getting said tickets assigned to individual developers (maybe at meeting, but not necessarily if good candidates aren't there). If they can't find someone--let's remember that this is open source--or decide they need to reprioritize/move/close, they'll be sure to explain this on the ticket. This is actually more or less what typically happens already informally (witness how Rüdiger takes responsibility for ensuring Engage tickets get triaged), but I assume adopters would like to be assured that we have a policy that assures them that they can count on their significant tickets not falling thru the cracks. (I think that tickets with a lower priority can remain assigned to the component so developers with time on their hands can filter for them and assign them to themselves. Maybe we designate one meeting a month to reviewing these.) Judy On Mar 29, 2012, at 8:43 AM, Hank Magnuski wrote: > 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 _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
