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
On Wed, Mar 28, 2012 at 9:24 AM, Tobias Wunden<[email protected]> wrote:
During today's adopters meeting, the issue has been brought up that there doesn't seem to be a good
process and practice in place for communication related to issues filed by "pure"
adopters, meaning individuals or institutions that are sometimes neither on IRC nor at the
developer meetings to "promote" their tickets (as a sidenote, both of these communication
channels / opportunities are open for everyone!).
Adopters were basically asking how the process could be improved, and it seems
like one major improvement would be if developers took a look at newly filed
tickets, classify and schedule them according to importance and resources and,
most importantly, add comments in case the ticket status (importance, fix
version, ...) is changed so that the adopter understands why a certain ticket
that he/she considers a blocker may not be a blocker by the developers.
Please add your thoughts and suggestions, in order for us to implement an
improved communication strategy. Note that I am cross-posting this message to
both the developers and the users list, but I think it would be beneficial to
keep the discussion on the the users list.
Tobias
_______________________________________________
Matterhorn-users mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
--
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail: [email protected]
Internet: www.virtuos.uni-osnabrueck.de
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
