Reading the feedback on this discussion, I created a wiki page at [1] which is
intended to support the developers and consolidate new tickets in one place, at
the same time communicating to the community what the process is with regards
to the tickets that are submitted.
Following the general movement in this discussion, I propose for the developers
to go through these tickets a couple of times a week, leaving those that they
are unsure of for the dev meeting.
In order for this to be efficient, I suggest the following rules for dealing
with new tickets:
1) Tickets are assigned a fix version other than "Trunk" if either of the
following is true:
- the developers decide that it's critical to fix
- resources are available to fix it
2) Tickets that do not contain enough information will be
- commented on to ask for the missing pieces of information
- remain unassigned
- will be resolved as "won't fix" if the reporter does not provide the
information with in reasonable time
Please note that right now the filter, which is sorted by date of creation in
descending order, contains 300+ items. It would be great if all of us could go
through it and make reasonable decisions to reduce the list to 0. As stated
above, tickets should be treated by the process that we defined just now.
Please let me know if you have additional comments. It would also be great to
hear from the developers if there is buy-in for this kind of process. If only a
few of us follow this proposal, it's not worth implementing and I am happy to
listen to other ideas to solve the problem.
Tobias
[1] http://opencast.jira.com/wiki/display/MH/Community+Feedback
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
