Good to see that this discussion is not only about quick fixes. This answer goes to wikidata-bugs but it is also applicable to Nobody.
On 12/07/2012 03:17 AM, Lydia Pintscher wrote:
On Thu, Dec 6, 2012 at 10:17 PM, Quim Gil qgil@wikimedia.org wrote:
On 12/06/2012 10:56 AM, Lydia Pintscher wrote:
For Wikidata at least we do set bugs to ASSIGNED most of the time. But we do leave the assignee set to the mailing list. If there is a strong preference to also change the assignee I can bring it up in the team.
Bitte bitte biiiitte! :)
Hey Quim,
I brought this up today in our daily meeting. It seems people do not think changing this is doable. The way we work in the team is that at the beginning of the sprint we set the tasks we'll be working on to assigned and add them to the task board in the office here. Then people pick things from the board as they go along during the sprint by putting a pin with their face on it on the task. Duplicating this information once again seems like it'll not get done... I think for people outside the team setting the status to assigned is enough. And if they want to know who exactly is working on it they can ask in the bug.
I just did: https://bugzilla.wikimedia.org/show_bug.cgi?id=42817
There is more at http://bit.ly/WO5wBk (my new saved search)
Let's see what happens. :)
Going through a sample of bugs ASSIGNED to Nobody and Wikidata it seems that each developer goes to their newly assigned bug reports and sets them to ASSIGNED (and CCing themselves). Is that the case or is there someone acting as proxy for the developers?
If they are the ones doing the work, how hard is to click "take"? This is now easier than CCing you.
If someone is doing the proxy work for the developers (as it happend too frequently when I worked at Nokia, and I have seen other corporations doing the same with public bug trackers) then the main risk is to have a disconnect between the reporter and the bug discussion and the actual work that someone else is doing inside an organization, because that developer is not even getting the feedback that bug might raise.
Adding the actual developer to the CC field helps fixing this problem but, once you are there, assigning the bug to the actual developer is just the same amount of work.
Conclusion: assigning bugs to the people that got them assigned is quite simple, a good open source software development practice and one factor helping getting more and better contributions.
My work consists in helping bringing more and better contributions to Wikimedia software projects, and this is why I care. I understand modifying processes is always an annoyance for busy teams but at least I hope you get what we all get (you included) for the price of a click.
Thank you for reading. :)
On Fri, Dec 7, 2012 at 5:30 PM, Quim Gil qgil@wikimedia.org wrote:
I just did: https://bugzilla.wikimedia.org/show_bug.cgi?id=42817
There is more at http://bit.ly/WO5wBk (my new saved search)
Let's see what happens. :)
My guess is that Daniel is working on that one. But he'll confirm.
Going through a sample of bugs ASSIGNED to Nobody and Wikidata it seems that each developer goes to their newly assigned bug reports and sets them to ASSIGNED (and CCing themselves). Is that the case or is there someone acting as proxy for the developers?
If they are the ones doing the work, how hard is to click "take"? This is now easier than CCing you.
If someone is doing the proxy work for the developers (as it happend too frequently when I worked at Nokia, and I have seen other corporations doing the same with public bug trackers) then the main risk is to have a disconnect between the reporter and the bug discussion and the actual work that someone else is doing inside an organization, because that developer is not even getting the feedback that bug might raise.
Adding the actual developer to the CC field helps fixing this problem but, once you are there, assigning the bug to the actual developer is just the same amount of work.
Conclusion: assigning bugs to the people that got them assigned is quite simple, a good open source software development practice and one factor helping getting more and better contributions.
My work consists in helping bringing more and better contributions to Wikimedia software projects, and this is why I care. I understand modifying processes is always an annoyance for busy teams but at least I hope you get what we all get (you included) for the price of a click.
Thank you for reading. :)
No I think we're talking past each other a bit ;-) Assigned means we (the Wikidata dev team) picked up the bug/task for the current sprint. It is not always immediately clear who is going to work on the bug during the sprint. It is just clear that we intend to work on it. This decision is made in a meeting of the whole team. At the end of the meeting someone goes and changes the bug status accordingly for all of them. During the sprint developers pick from that list as they wish/have the skills.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
On 12/07/2012 09:01 AM, Lydia Pintscher wrote:
No I think we're talking past each other a bit ;-) Assigned means we (the Wikidata dev team) picked up the bug/task for the current sprint. It is not always immediately clear who is going to work on the bug during the sprint. It is just clear that we intend to work on it. This decision is made in a meeting of the whole team. At the end of the meeting someone goes and changes the bug status accordingly for all of them. During the sprint developers pick from that list as they wish/have the skills.
Then those ASSIGNED bugs are not really assigned. By setting as ASSIGNED nobody else will attempt to fix them, but then again perhaps nobod is working on them and nobody will actally have the time to work on them on the current sprint, being postponed when perhaps someone else would have taken them.
A more accurate approach would be to set those bugs to "Highest" priority in order to identify them for the current sprint. This is less than "Immediate" (something requiring immediate action) and more than "High" (something important, perhaps for the next sprint).
On Fri, Dec 7, 2012 at 6:08 PM, Quim Gil qgil@wikimedia.org wrote:
Then those ASSIGNED bugs are not really assigned. By setting as ASSIGNED nobody else will attempt to fix them, but then again perhaps nobod is working on them and nobody will actally have the time to work on them on the current sprint, being postponed when perhaps someone else would have taken them.
Yes the whole point of that exercise is among other things to make sure no-one else takes them. There are a lot of bugs that people can work on if they wish. There are even over 50 of them marked as need-volunteer explicitly.
A more accurate approach would be to set those bugs to "Highest" priority in order to identify them for the current sprint. This is less than "Immediate" (something requiring immediate action) and more than "High" (something important, perhaps for the next sprint).
See above.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
wikitech-l@lists.wikimedia.org