Page MenuHomePhabricator

[WikiDev17] Developer Wishlist
Closed, ResolvedPublic

Description

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

@Tgr

Interested attendees (sign up below)

  1. @Qgil
  2. 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.

Event Timeline

Tgr created this task.Oct 31 2016, 10:05 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 31 2016, 10:05 PM
Qgil added a subscriber: Qgil.Nov 22 2016, 1:17 PM

I think this is an interesting idea... if we can assure some resources devoted to the winners. What makes the Community Wishlist attractive is the fact that the Community-Tech team commits to work on the most voted proposals. Thanks to that attraction, other benefits come along (a prioritized list of wanted features is an interesting reference for volunteer developers, our hackathons, etc).

Maybe at the Summit we can talk a bit in theory, and then do our best backing up the idea with resources in the FY2017-18 annual plan. I am not saying that no progress is possible without resources committed, but having this goal understood and shared between the Technology, Product, and Community Engagement should definitely help.

Tgr updated the task description. (Show Details)Nov 27 2016, 8:15 AM
Tgr added a comment.Nov 27 2016, 8:21 AM

@Qgil as it happens I have a proposal for that :) (although it has been in stasis for a while)
But I think having a list would be valuable even without resourcing as it could guide volunteer efforts, internships etc, and it would also help demonstrate the need for resourcing (and clarify how those resources would be allocated).

Qgil added a subscriber: srishakatux.

@Qgil as it happens I have a proposal for that :) (although it has been in stasis for a while)

Interesting proposal. I think whoever is interested on it should make a strong push aiming at the Wikimedia Foundation Annual Plan FY2017-18. Also with a new CTO... If not now, then when.

Back to the proposal here:

But I think having a list would be valuable even without resourcing as it could guide volunteer efforts, internships etc, and it would also help demonstrate the need for resourcing (and clarify how those resources would be allocated).

OK, that makes sense as well. Organizing a developer wishlist sounds like a potential goal within the Developer-Advocacy domain. Let's start discussing how a first edition could look like. If this first round would be light and allowing for experimentation, maybe we could start working on it before June 2017. If we want something more polished and demanding, then let's discuss it having the FY 2017-18 plan in mind. No matter what, if we want to keep doing this annually, we should think of including it in our annual plan.

Tgr added a comment.Nov 29 2016, 12:20 AM

Yeah, I'd definitely like to have a list by the time annual planning kicks off. I was thinking of just plagiarizing much of the Communit Wishlist Survey process: come up with a list of areas based on types of developer (frontend, backend, ops, apps... also maybe new / experienced), and a list of notification channels, and then just have a discussion on-wiki, followed by a vote. I think that should be doable with a month of preparation plus a month of surveying.

@Tgr Hey! As developer summit is less than four weeks from now, we are working on a plan to incorporate the ‘unconference sessions’ that have been proposed so far and would be generated on the spot. Thus, could you confirm if you plan to facilitate this session at the summit? Also, if your answer is 'YES,' I would like to encourage you to update/ arrange the task description fields to appear in the following format:

Session title
Main topic
Type of activity
Description Move ‘The Problem,' ‘Expected Outcome,' ‘Current status of the discussion’ and ‘Links’ to this section
Proposed by Your name linked to your MediaWiki URL, or profile elsewhere on the internet
Preferred group size
Any supplies that you would need to run the session e.g. post-its
Interested attendees (sign up below)

  1. Add your name here

We will be reaching out to the summit participants next week asking them to express their interest in unconference sessions by signing up.

Tgr updated the task description. (Show Details)Dec 16 2016, 7:36 AM

I do plan to facilitate.

To maintain the consistency, please consider referring to the template of the following task description: https://phabricator.wikimedia.org/T149564.

Tgr updated the task description. (Show Details)Dec 16 2016, 8:52 AM
Qgil updated the task description. (Show Details)Dec 20 2016, 10:59 AM
Qgil awarded a token.

To the facilitator of this session: We have updated the unconference page with more instructions and faqs. Please review it in detail before the summit: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Unconference. If there are any questions or confusions, please ask! If your session gets a spot on the schedule, we would like you to read the session guidelines in detail: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines. We would also then expect you to recruit Note-taker(s) 2(min) and 3 (max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be available in all the session rooms! See you at the summit! :)

Note-taker(s) of this session: Follow the instructions here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines#NOTE-TAKER.28S.29 After the session, DO NOT FORGET to copy the relevant notes and summary into a new wiki page following the template here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Your_Session and also link this from the All Session Notes page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/All_Session_Notes. The EtherPad links are also now linked from the Schedule page (https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Schedule) for you!

Tgr updated the task description. (Show Details)Jan 9 2017, 10:50 PM
Tgr updated the task description. (Show Details)Jan 9 2017, 10:58 PM
Qgil updated the task description. (Show Details)Jan 9 2017, 11:53 PM

I've created an on-wiki draft page at https://www.mediawiki.org/wiki/Developer_Wishlist — get editing!

Etherpad notes from this session: https://etherpad.wikimedia.org/p/devsummit17-developer-wishlist @Jdforrester-WMF, are these all included on the on-wiki draft? If possible, would you mind folding them in so there's one resource available for this session? Thank you!

Etherpad notes from this session: https://etherpad.wikimedia.org/p/devsummit17-developer-wishlist @Jdforrester-WMF, are these all included on the on-wiki draft? If possible, would you mind folding them in so there's one resource available for this session?

No. The page on wiki is an action arising from the work, not a minute of the discussion. I don't think it would be appropriate to try to merge the objectives.

Sounds good! Thanks for clarifying @Jdforrester-WMF

Qgil added a comment.Jan 15 2017, 11:49 PM

Beyond the Summit session, the actual work is being coordinated at T155387: Organize the first Developer Wishlist survey and related tasks.

Qgil triaged this task as Normal priority.Jan 24 2017, 10:57 AM

Is there any additional outcome expected from this task?

Tgr closed this task as Resolved.Feb 17 2017, 1:25 AM