Wikimedia Developer Summit/2017/Developer Wishlist

From MediaWiki.org
Jump to navigation Jump to search
Session recording

Discussion Topics[edit]

  • Desire for a wishlist
  • Scope for possible entries
  • Process/mechanism for running a vote(?) and getting things on the list done

Detailed Summary[edit]

  • Gergo introduces the session as explained in task description.
  • Initial idea was just to copy the Community Wishlist. Come up with some categorization (Frontend, Backend...). People can create proposals, vote, etc.
  • It would be great to get some commitment to work on the top tasks, but Gergo doesn't think it would need to be a requirement.
  • Having a list is important enough. The prioritization would help the right people to pay more attention.
  • JamesF: first reaction, I think you are right, but it might be useful to give an indication of scope and size of desired projects (i.e. imagine top task is "rewrite MediaWiki"). The resulting list should be actionable, not just "come up with a new RfC", something that could be done by a volunteer in a time period between a few days and a month (e.g.).
  • Quim: Audience is more homogeneous, so we could have a longer triaging process. Different from the community wishlist — more managable maybe?
  • Shouldn't overlap with the community wishlist. Developers proposing tasks for developers is different than editor proposing tasks for developers. "If it's suitable for including on the Community Wishlist it should be out of scope for the Developer Wishlist."
  • Where do we draw the line? Are Lua writers on-wiki Community Wishlist people or Developer WIshlist people? Gadget authors?
  • What about documentation? Absolutely in scope, if specfic and actionable.
  • Who would organise this? Gergő because he suggested it? Quim's team might be able to help out too
  • Why is this better than just creating a task? Phabricator is not well suited for discussing prioritization.
  • Maybe the process could be more Phabricator based. Having a #developer-wishlist tag would be useful alredy, because now these requests are spread all over.
  • Good ranking in DW could also be a good way to i.e. getting your stuff reviewed and merged, rather than being stuck in development hell.
  • Could use AllOurIdeas (or something similar) because of the (more) homogenous developer community meaning people can express a preference between pairs, so tasks don't just get lots of drive-by votes, they have to directly beat others to rank highly.
  • Maybe other voting systems, no need to decide now. This is an exercise in prioritization, not democracy.
  • Technical Collaboration should be able to help organizing this.
  • Phases: there should be phases for proposing tasks, for asking questions about proposals, refine / merge...
  • Important to have rounds of clarification and questions — is the alternative that's "similar" according to someone OK for them? Etc.
  • Yaron: We should hire someone to write documentation.
  • Difficult... (a bit of side discussion about developer should write documentation, what happened to our tech writer...)
  • This ties into a technical roadmap, and it seems that the CTO should be responsable for this. Is this is a top bottom or bottom up thing?
  • JamesF: This wishlist should be good to help working on things benefiting not just the Wikimedia people (scope of the CTO) but also the non-Wikimedia developers.
  • DW has potential to raise attention on problems that fall between the cracks between they don't fall into a specific WMF team/project.
  • Audience: which developers? 
  • Gergo: I don't think there is a need to differentiate between Wikimedia and third parties.
  • Extension developers, anybody using APIs.
  • The question is relevant in order to know who to reach to participate in the survey.
  • On the other hand, learning from the CW, let's not get too obsessed: organize the first, and the second one will be better.
  • "Quality of life" improvements – not just filing bugs / documentation, also …
  • Good thing about having a smaller and more homogeneous community is that if e.g. the 7th task is fixing something in Gerrit and we know that's not going to happen, we can simply agree to this and move on to the 8th.
  • Technical Collaboration to take responsibility of organizing, having Gergo as check point for whatever needs extra clarification / complex decision.
  • (Side discussion about improvements in setting up development environment.)
  • (Started to rain, attendees started to ramble about fun topics)  :)

Action Items[edit]

  • WHO?: Agree that this is a resonable idea.
    • DONE
  • Quim for Technical Collaboration: Set a timeline, set criteria, announce it. — Try to get the vote finished by mid-February 2017 in order to impact Annual Plan.
  • Quim for Technical Collaboration: Declare things as in/out of scope, add to voting mechanism, run the vote.