Talk:Developer Wishlist

Sorry if I've missed it – is there a collective evaluation of the 2017 wishlist process somewhere? Was there a reason why one wasn't organized for 2018?

In my personal opinion, being asked to express wishes often creates an expectation that someone will take care of fulfilling these wishes. That requires a process and assigning available resources. The latter is not the case so far, as far as I know. Also see discussion in https://phabricator.wikimedia.org/T149635

It did not seem worth the effort as fairly little progress happened on the 2017 tasks. See T158149 and T158148. It was an experiment that, at least in its current, voluntary form, did not work out. Or maybe it wasn't about the voluntary part but lack of being actively promoted through the year.

Also, I don't think priorities change so much during 1-2 years so if some group wants to fix developer pain points, IMO the 2017 list is still a fine starting point today.

Thanks @James and @Quim for getting this started!

Two initial ideas for the process:

1. just ape the CT wishlist. Same format, same voting system, ask the CT team to run the proposal randomizer bot for us.

   Pro: little effort, proven to work, relatively nitpicking-safe, wikitext is good at presenting long discussions in a very concise manner

   Con: probably a barrier to entry for devs who are not editors themselves, we don't learn much about voters

2. run the first phase of the CT wishlist (solicit wishes and have discussions about them), possibly in Phabricator instead of a wiki, then set up a simple form (Google Forms?) for getting votes + demographic information of voters (core contributor? works with MediaWiki how often? for money? etc) + maybe information about the specific vote (how often are you obstructed by this issue?)

   Pro: more inclusive (I think?), gives a lot of information that's good for prioritizing, helps us understand what kind of people use MediaWiki which is something we know embarrassingly little about

   Con: voting is not transparent (if we actually make use of the extra information then not really a voting at all), lot of effort to process all the feedback

Let's go for wishes proposed directly in Phabricator, which saves a lot of centralized work for the organizers and avoids duplication.

This should not condition how we want to vote. All options are still open, including classical votes in wiki pages. That deserves a discussion on its own, that we can have while people submit their wishes.

Sure, let's go for it. Want to work on the announcement?

As discussed at WikiDev, we probably should split the list into sections to make it easier for people to review existing proposals before submitting new ones, and to make sure important areas affecting less tech people (e.g. operations) also get some visibility. Here is an initial suggestion (based on what kind of skill is required to implement proposals):

• Frontend
• Backend
• API (ie. wishes by developers who make API calls)
• [Dev]Ops (does this make sense?)
• Documentation
• Enviroment (IDE integration, Vagrant etc)
• Contribution workflow (Phab, gerrit, CI)

Yes, categories will be useful. Do we need to decide them beforehand, or can we create them based on the proposals received? They could be columns in a Phabricator board.

Creating them up-front will probably help people think of their concerns. Next iteration we can tweak the columns. Maybe have an "Other" for other suggestions?

OK, please check https://phabricator.wikimedia.org/project/board/2436/.

"Frontend" and "Backend"... are these clear concepts in the context of the developer wishlist? Are we talking about... technical debt?

We need to be cautious about people perceiving that they can propose i.e. "power user frontend features" or anything in that direction.

Technical debt and tooling.

I don't think mistaken submissions are particularly problematic, just remove the wishlist project and treat them as normal feature requests.

OK, makes sense.

Clicking on Vote/Endorse does not seem to have any effect. If these button-looking elements are meant to be more like "Headlines", please remove them. If they are meant to trigger an action, I could try to find the reason for it.

I get a "Vote for this proposal: [Cancel] [Vote]" overlay popup in FF51.

They are meant to trigger MediaWiki:Gadget-addMe.js (which was adopted about an hour before voting started, in a rush job, and so aren't high quality). Debugging is much appreciated. You can see from the page histories that it works for most people so I would suspect some browser-specific issue.

Tracked in Phabricator
Task T155866

Some ideas:

• mailing lists (wikitech-l, mediawiki-l/mediawiki-announce, mediawiki-api/mediawiki-api-announce, wikitech-ambassadors, possibly anything else with a decent number of subscribers)
• banner campaign (mediawiki.org, wikitech, possibly other wikis?)
• messages to technical village pumps
• Tech News
• Phabricator?
• gerrit?
• MediaWiki Facebook + Linkedin group(s?)
• Paid ads? (Stackoverflow can run tag-specific ads; Linkedin, Facebook can run skill-specific ads)
• IRC messages?
• direct emails based on Phab/gerrit/whatever account information?

Wikitech-l: https://lists.wikimedia.org/pipermail/wikitech-l/2017-January/087387.html

With this, I am not the bottleneck for further promotion of the survey anymore. I have to jump to a flight in a few minutes! See you later.  :)