Session title
Developer Wishlist
Main topic
How to manage our technical debt, How to grow our technical community
Type of activity
unconference session
Description
1. The problem
Developers are people too! Just like readers and editors, a poor user experience can drive them away and make them spend their time on some other project instead, while a great user experience can allow them to work more focused and more effectively. Developer experience (DX) affects everything from the slope of the learning curve to volunteer and staff retention to work efficiency.
Despite the importance, DX does not get much "official" attention; the continuous integration infrastructure has an owner but most other related functionality (such as documentation and consistent interfaces, logging and error reporting, debugger and development environment integration) is improved on an ad hoc basis. That tends to result in prioritization reflecting the needs of the people doing that ad hoc work; even if they want to focus on what is going to have the highest impact, they don't have the resources to figure out what that is.
Wikimedia tool/feature development for experienced editors used to suffer from the same problem, and the Community Wishlist proved to be an effective tool to get around that problem. Maybe that success is something that can be copied; should we try to create a Developer Wishlist that can be used to direct attention to the important platform-level issues the same way the Community Wishlist directs attention to the important feature-level issues?
2. Expected outcome
Agreement about a Developer Wishlist being a worthy goal, and a process for creating it. Or agreement that this is a silly idea and should not pursued.
3. Current status of the discussion
4. Links
Proposed by
Interested attendees (sign up below)
- @Qgil
- Add your name here
Etherpad: https://etherpad.wikimedia.org/p/devsummit17-developer-wishlist
Quick paste of etherpad
SESSION OVERVIEW
Title: Developer Wishlist
Day & Time: Monday 2017-01-09 14:50–16:00
Room: Chapel Hill
Phabricator Task Link: https://phabricator.wikimedia.org/T149635
Facilitator(s):
Note-Taker(s): Quim Gil, James Forrester
Remote Moderator: N/A (no remote facilities in this room)
Advocate: Gergő Tisza
SESSION SUMMARY
Topics for discussion:
- Desire for a wishlist
- Scope for possible entries
- Process/mechanism for running a vote(?) and getting things on the list done
Chronology: [Capture the gist of who said what, in what order. A transcript isn't necessary, but it's useful to capture the important points made by speakers as they happen]
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:
- 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.