Hi everyone,
As I'm sure you're aware, by virtue of my job's scope I sometimes find areas of attention where a little bit of engineering work would result in a reasonably sized improvement from a product and user experience standpoint. Often these problems are ill-defined by the user reporting them, which obscures the actual simplicity of the problem and deters engineers from working on them.
I have been raising these issues from time to time in our weekly meetings. I've thought about that, and decided that that meeting is long enough already without me trying to cram more into it. I think a large part of the lukewarm response I get trying to recruit people to do these things is due to the forum I'm raising these issues in. So I've got an alternative solution: product microtasks(tm) [1].
Product microtasks are problems that have been reported by a user that I have assessed, prioritised, and defined a clear-cut engineering solution for. If you're stuck on your current project and want something else to work on to cleanse your programming palate, you can do one of these. The intention for these is that they're little discrete chunks of work that are easy for you to pick up and not have to worry about defining the solution, just implementing it.
The list can be found at https://www.mediawiki.org/wiki/Platform_product_microtasks, and could be thought of as "annoying little bugs for more experienced developers".
Be warned, I may still bug people from time to time to attend to specific issues. That is a sign of love and a mark of respect. Really. ;-)
Thanks, Dan
[1]: Yeah, alright, you got me. I've not actually trademarked it. Don't spoil my fun. :-(
On Wed, Apr 9, 2014 at 3:53 PM, Dan Garry dgarry@wikimedia.org wrote:
I have been raising these issues from time to time in our weekly meetings. I've thought about that, and decided that that meeting is long enough already without me trying to cram more into it. I think a large part of the lukewarm response I get trying to recruit people to do these things is due to the forum I'm raising these issues in. So I've got an alternative solution: product microtasks™ [1].
Product microtasks are problems that have been reported by a user that I have assessed, prioritised, and defined a clear-cut engineering solution for. If you're stuck on your current project and want something else to work on to cleanse your programming palate, you can do one of these. The intention for these is that they're little discrete chunks of work that are easy for you to pick up and not have to worry about defining the solution, just implementing it.
I think this is a good idea! I also think you should go ahead and continue raising these tasks in our weekly meeting. Perhaps we could make microtasks be one of our regular sections in the Google doc. I think your effort to articulate the scope and selection criteria for these tasks will make recruiting developer time easier.
Le 10/04/2014 00:53, Dan Garry a écrit :
The list can be found at https://www.mediawiki.org/wiki/Platform_product_microtasks, and could be thought of as "annoying little bugs for more experienced developers".
http://www.mediawiki.org/wiki/Annoying_little_bugs is a nice page, I point our India volunteers to it constantly (no clue if it has any effects though).
I tend to dislike MediaWiki to maintains backlog lists. Maybe we could use:
- a keyword or tracking bug in Bugzilla. - phabricator , I would not mind start being used to it - trello (yet another tool)
We used to do weekly reviews of bugs keyworded platformeng. The are 111 of bugs so you would have a hard time raising attention for the micro tasks though :( https://bugzilla.wikimedia.org/buglist.cgi?keywords=platformeng
Antoine,
Allow me to explain my motivations a bit. Perhaps it will become clearer then. :-)
As a team, we have responsibilities. For example, that task that's on there right now is a problem caused by our actions; we pulled that extension for security reasons, then decided we couldn't reenable it due to design issues. Therefore our actions have caused a very real regression in our user experience. As the product manager, I find these regressions concerning, and we have a responsibility to fix them.
Right now, my only recourse to fix these user experience regressions is to ask politely for someone from the team to help me. I typically get a lukewarm response to these requests. Meanwhile, I get a fair amount of abuse directed at me by volunteers for not fixing these problems, because I am the public face of the team and it (outwardly) looks like we don't care to fix these relatively simple problems. Sure, it sucks for us to do these random tasks, but it sucks hard for our users too. We lose a lot of credibility with some of our volunteers for it.
So what I'm trying to do here is make it as easy as humanely possible for you guys, the overworked engineers, to pick these tasks up and get them done. At the same time, I don't want to get sucked into maintaining control over the task list, so mediawiki.org was the simplest solution.
I hope that helps explain things a bit.
Thanks, Dan
On 10 April 2014 09:03, Antoine Musso amusso@wikimedia.org wrote:
Le 10/04/2014 00:53, Dan Garry a écrit :
The list can be found at https://www.mediawiki.org/wiki/Platform_product_microtasks, and could be thought of as "annoying little bugs for more experienced developers".
http://www.mediawiki.org/wiki/Annoying_little_bugs is a nice page, I point our India volunteers to it constantly (no clue if it has any effects though).
I tend to dislike MediaWiki to maintains backlog lists. Maybe we could use:
- a keyword or tracking bug in Bugzilla.
- phabricator , I would not mind start being used to it
- trello (yet another tool)
We used to do weekly reviews of bugs keyworded platformeng. The are 111 of bugs so you would have a hard time raising attention for the micro tasks though :( https://bugzilla.wikimedia.org/buglist.cgi?keywords=platformeng
-- Antoine "hashar" Musso
MediaWiki-Core mailing list MediaWiki-Core@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-core
Hi,
1. Very good idea, and thank you for helping triaging the little tasks that don't make it to your backlogs.
2. For what is worth, Annoying_little_bugs moved from being a list curated manually to point to Bugzilla queries, focusing there the work or triaging and prioritization.
3. Andre and me are looking for a good activity to restart our monthly Bug Day. Could it be an activity helping to fish these microtasks?
On Thursday, April 10, 2014, Dan Garry dgarry@wikimedia.org wrote:
Antoine,
Allow me to explain my motivations a bit. Perhaps it will become clearer then. :-)
As a team, we have responsibilities. For example, that task that's on there right now is a problem caused by our actions; we pulled that extension for security reasons, then decided we couldn't reenable it due to design issues. Therefore our actions have caused a very real regression in our user experience. As the product manager, I find these regressions concerning, and we have a responsibility to fix them.
Right now, my only recourse to fix these user experience regressions is to ask politely for someone from the team to help me. I typically get a lukewarm response to these requests. Meanwhile, I get a fair amount of abuse directed at me by volunteers for not fixing these problems, because I am the public face of the team and it (outwardly) looks like we don't care to fix these relatively simple problems. Sure, it sucks for us to do these random tasks, but it sucks hard for our users too. We lose a lot of credibility with some of our volunteers for it.
So what I'm trying to do here is make it as easy as humanely possible for you guys, the overworked engineers, to pick these tasks up and get them done. At the same time, I don't want to get sucked into maintaining control over the task list, so mediawiki.org was the simplest solution.
I hope that helps explain things a bit.
Thanks, Dan
On 10 April 2014 09:03, Antoine Musso <amusso@wikimedia.orgjavascript:_e(%7B%7D,'cvml','amusso@wikimedia.org');
wrote:
Le 10/04/2014 00:53, Dan Garry a écrit :
The list can be found at https://www.mediawiki.org/wiki/Platform_product_microtasks, and
could
be thought of as "annoying little bugs for more experienced developers".
http://www.mediawiki.org/wiki/Annoying_little_bugs is a nice page, I point our India volunteers to it constantly (no clue if it has any effects though).
I tend to dislike MediaWiki to maintains backlog lists. Maybe we could use:
- a keyword or tracking bug in Bugzilla.
- phabricator , I would not mind start being used to it
- trello (yet another tool)
We used to do weekly reviews of bugs keyworded platformeng. The are 111 of bugs so you would have a hard time raising attention for the micro tasks though :( https://bugzilla.wikimedia.org/buglist.cgi?keywords=platformeng
-- Antoine "hashar" Musso
MediaWiki-Core mailing list MediaWiki-Core@lists.wikimedia.orgjavascript:_e(%7B%7D,'cvml','MediaWiki-Core@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/mediawiki-core
-- Dan Garry Associate Product Manager for Platform Wikimedia Foundation
On 10 April 2014 14:30, Quim Gil qgil@wikimedia.org wrote:
- Andre and me are looking for a good activity to restart our monthly Bug
Day. Could it be an activity helping to fish these microtasks?
I'm in. Are you guys going to do this over Google Hangout?
I want to keep this list fairly manageable though, so we should pick only the most important things to put in there.
Dan
On Thu, 2014-04-10 at 14:39 -0700, Dan Garry wrote:
On 10 April 2014 14:30, Quim Gil qgil@wikimedia.org wrote:
- Andre and me are looking for a good activity to restart our monthly Bug
Day. Could it be an activity helping to fish these microtasks?
I'm in. Are you guys going to do this over Google Hangout?
I want to keep this list fairly manageable though, so we should pick only the most important things to put in there.
I'd love to have more criteria how I myself could realize that I am looking at such a microtask when I'm reading and triaging Bugzilla tickets, in order to notify Dan about good candidates. Probably the feeling that it's a narrow scope, that a developer has already described what's the way forward, but that's it's not an entirely trivial problem?
If I get it correctly, "Platform product microtasks" are not for beginners (hence not a subgroup of Bugzilla's "easy" keyword defined as "Self-contained, non-controversial issues with a clear approach which are recommended to try for new developers") but developers who have already contributed some patches to MediaWiki, hence could be the "next level" after "easy" tasks have gotten too easy for somebody?
Except for product scope, what are the differences to the use of "papercut" in the Bugzilla whiteboard entry by the Wikidata team? See https://www.wikidata.org/wiki/Wikidata:Paper_cuts
Cheers, andre
Hi,
On Thu, 2014-04-10 at 14:30 -0700, Quim Gil wrote:
- Very good idea, and thank you for helping triaging the little tasks that
don't make it to your backlogs.
- For what is worth, Annoying_little_bugs moved from being a list curated
manually to point to Bugzilla queries, focusing there the work or triaging and prioritization.
- Andre and me are looking for a good activity to restart our monthly Bug
Day. Could it be an activity helping to fish these microtasks?
As we just turned the outdated and non-curated [[mw:Annoying_little_bugs]] into queries pointing to open tickets with the easy keyword in Bugzilla, I'm just a bit worried that [[mw:Platform_product_microtasks]] could end up in a similar situation at some point if not constantly curated and updated, however if Dan says that the list should remain small I'm more positive.
Also, how advertised is that wikipage? Could I find out about the listed task(s) somehow without knowing of the existence and the address of this specific wikipage? I'm asking because bugzilla.wikimedia.org might be a slightly more established address when looking for coding tasks (if you will be able to find the tasks fitting your skills and interest is a different question though).
Furthermore, when moving the inclusion criteria of "Annoying little bugs" into Bugzilla (by using the "easy" keyword) I also had external services like openhatch.org in mind which intend to offer well-defined tasks for beginners in a project.
All this doesn't need to be answered, just pointing out problems and thoughts in the past related to "Annoying little bugs".
andre
On Thursday, April 10, 2014, Dan Garry dgarry@wikimedia.org wrote:
Antoine,
Allow me to explain my motivations a bit. Perhaps it will become clearer then. :-)
As a team, we have responsibilities. For example, that task that's on there right now is a problem caused by our actions; we pulled that extension for security reasons, then decided we couldn't reenable it due to design issues. Therefore our actions have caused a very real regression in our user experience. As the product manager, I find these regressions concerning, and we have a responsibility to fix them.
Right now, my only recourse to fix these user experience regressions is to ask politely for someone from the team to help me. I typically get a lukewarm response to these requests. Meanwhile, I get a fair amount of abuse directed at me by volunteers for not fixing these problems, because I am the public face of the team and it (outwardly) looks like we don't care to fix these relatively simple problems. Sure, it sucks for us to do these random tasks, but it sucks hard for our users too. We lose a lot of credibility with some of our volunteers for it.
So what I'm trying to do here is make it as easy as humanely possible for you guys, the overworked engineers, to pick these tasks up and get them done. At the same time, I don't want to get sucked into maintaining control over the task list, so mediawiki.org was the simplest solution.
I hope that helps explain things a bit.
Thanks, Dan
On 10 April 2014 09:03, Antoine Musso <amusso@wikimedia.orgjavascript:_e(%7B%7D,'cvml','amusso@wikimedia.org');
wrote:
Le 10/04/2014 00:53, Dan Garry a écrit :
The list can be found at https://www.mediawiki.org/wiki/Platform_product_microtasks, and
could
be thought of as "annoying little bugs for more experienced developers".
http://www.mediawiki.org/wiki/Annoying_little_bugs is a nice page, I point our India volunteers to it constantly (no clue if it has any effects though).
I tend to dislike MediaWiki to maintains backlog lists. Maybe we could use:
- a keyword or tracking bug in Bugzilla.
- phabricator , I would not mind start being used to it
- trello (yet another tool)
We used to do weekly reviews of bugs keyworded platformeng. The are 111 of bugs so you would have a hard time raising attention for the micro tasks though :( https://bugzilla.wikimedia.org/buglist.cgi?keywords=platformeng
-- Antoine "hashar" Musso
MediaWiki-Core mailing list MediaWiki-Core@lists.wikimedia.orgjavascript:_e(%7B%7D,'cvml','MediaWiki-Core@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/mediawiki-core
-- Dan Garry Associate Product Manager for Platform Wikimedia Foundation
Le 10/04/2014 23:11, Dan Garry a écrit : <snip>
As a team, we have responsibilities. For example, that task that's on there right now is a problem caused by our actions; we pulled that extension for security reasons, then decided we couldn't reenable it due to design issues. Therefore our actions have caused a very real regression in our user experience. As the product manager, I find these regressions concerning, and we have a responsibility to fix them.
Hello,
In this specific case, if the security is solved we can probably reenable it despite its design issue unless that causes performances or more security issues (or maybe it is flawed by design).
Right now, my only recourse to fix these user experience regressions is to ask politely for someone from the team to help me. I typically get a lukewarm response to these requests. Meanwhile, I get a fair amount of abuse directed at me by volunteers for not fixing these problems, because I am the public face of the team and it (outwardly) looks like we don't care to fix these relatively simple problems. Sure, it sucks for us to do these random tasks, but it sucks hard for our users too. We lose a lot of credibility with some of our volunteers for it.
I understand your pain. On the other hand I don't think our team has any bandwidth left to get tiny changes in. Despite being named 'MediaWiki core' our scope is much larger than simply developing MediaWiki. A lot of the simple development is happily delegated to volunteers and we act as a gate to the production.
So yeah it certainly sucks to have nobody to respond, that is probably because nobody has time to spend to write such features. I myself landed 10 commits to core over the last 6 months, the longest one has been actually written by Ori and the rest are tiny tweaks for tests or the beta cluster.
So sure, I could spend half a day figuring out how to fix those micro product tasks but our awesome volunteers will be more efficient than me at that task.
So what I'm trying to do here is make it as easy as humanely possible for you guys, the overworked engineers, to pick these tasks up and get them done. At the same time, I don't want to get sucked into maintaining control over the task list, so mediawiki.org http://mediawiki.org was the simplest solution.
Fair, that is probably the easiest tool for you to maintain such a backlog. I guess as long as you point folks to it constantly, there is some chance that the entries will eventually be processed. I personally tend to drop watch list notifications :-(
On Fri, Apr 11, 2014 at 4:55 AM, Antoine Musso amusso@wikimedia.org wrote:
Le 10/04/2014 23:11, Dan Garry a écrit :
<snip> > As a team, we have responsibilities. For example, that task that's on > there right now is a problem caused by our actions; we pulled that > extension for security reasons, then decided we couldn't reenable it due > to design issues. Therefore our actions have caused a very real > regression in our user experience. As the product manager, I find these > regressions concerning, and we have a responsibility to fix them.
In this specific case, if the security is solved we can probably reenable it despite its design issue unless that causes performances or more security issues (or maybe it is flawed by design).
I disagree: that extension shouldn't have been enabled in the first place. Drastically rearranging [[Special:Watchlist]] and [[Special:RecentChanges]] for everyone based on three people responding to a poll seems insufficient consensus to me.
And given the followup conversation at https://meta.wikimedia.org/wiki/Meta:Babel/Archives/2013-10#Enable_CleanChan... it was enabled, there should probably be a new, well-advertised discussion before re-enabling it.
Le 11/04/2014 16:01, Brad Jorsch (Anomie) a écrit :
I disagree: that extension shouldn't have been enabled in the first place. Drastically rearranging [[Special:Watchlist]] and [[Special:RecentChanges]] for everyone based on three people responding to a poll seems insufficient consensus to me.
And given the followup conversation at https://meta.wikimedia.org/wiki/Meta:Babel/Archives/2013-10#Enable_CleanChan... after it was enabled, there should probably be a new, well-advertised discussion before re-enabling it.
Wasn't aware of the context sorry. I thought it was a well known extension that got temporarily disabled for security reasons and "unfairly" left disabled after the sec issue :]
Thank you for the useful links!
mediawiki-core@lists.wikimedia.org