Ruediger & Tobias, > 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
Hank, you would be fine if we just add to our process to discuss bugs at the meeting, not necessarily assign them? > We should create public filters that any developer should check > frequently. Agreed. > 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. The QA and RM don't drive the release, they manage it. Developers drive the release, and should be responsible for taking up bugs. > > 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" Components don't fix bugs, people do. If they are on holidays/etc. then the bug waits. Everyone can see it's still a bug by looking at the upcoming release and "affects version" tickets that aren't closed. If not one else wants to take it up, how does assigning it to a component make it better? Chris -- Christopher Brooks, BSc, MSc ARIES Laboratory, University of Saskatchewan Web: http://www.cs.usask.ca/~cab938 Phone: 1.306.966.1442 Mail: Advanced Research in Intelligent Educational Systems Laboratory Department of Computer Science University of Saskatchewan 176 Thorvaldson Building 110 Science Place Saskatoon, SK S7N 5C9 _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
