Page MenuHomePhabricator

Decide voting process for the Developer Wishlist
Closed, ResolvedPublic

Description

We need to decide a voting system for the Developer Wishlist, and quick.

The default reference is the Community Wishlist, where

  • the process runs on-wiki
  • wishes are organized in categories for better review
  • logged in users can vote {{support}} to as many wishes as they want
  • at the end of the voting period, a general ranking is published, and also rankings per category.

We are open to try alternatives if there is a good reasoning behind. Any candidates?

Event Timeline

@srishakatux @Tgr it would be great if any of you could own this task and this decision. Or both, since you happen to work side by side. :)

Tgr added a comment.Jan 17 2017, 10:41 PM

Phabricator and Flow do not have a useful voting tool and SecurePoll focuses on elections (high security and privacy but poor UI and admin interface); the only reasonable alternative I can think of is some online poll like SurveyMonkey (which is non-free and comes with privacy issues, but offers better UX and the possibility of collecting some extra information (it would be cool to see which wishes were the most popular with people new to MediaWiki, for example)).

Are you thinking of asking for any user data in addition to the votes?

srishakatux added a comment.EditedJan 18 2017, 10:01 PM

I like the way we run Community Wishlist survey a lot. Because the proposals and voting are clearly visible to everyone on the wikis, it reflects a fair process and I can't think of better alternatives to run this!

@Qgil How can I help more on this?

4nn1l2 added a subscriber: 4nn1l2.Jan 19 2017, 5:57 AM

Use OpaVote if you want a reasonable voting system. Learn from Stack Exchange.

Qgil added a comment.EditedJan 19 2017, 10:04 AM

@4nn1l2 are you advocating for a preferential voting system? I like these a lot, but I am not sure they work well when there are dozens of candidates (as opposed to just a handful).

If you are referring to a better UI than adding votes to wiki pages, that is a different discussion... I wonder if VisualEditor + copy&paste votes would work. I haven't tried.

Another factor to consider is to prevent abuse (through endless anonymous votes), or having to register in third party commercial systems. A difficult balance. Votes by registered users in mediawiki.org would provide certain balance.

In other words, I am not a fan of votes in wiki pages, but given the current circumstances I am wondering whether we have a better choice worth the effort.

4nn1l2 added a comment.EditedJan 19 2017, 2:24 PM

I have no idea how many proposals you will have for each category, but you are right; alternative voting systems are not an optimal choice when there are dozens of candidates because they can overwhelm the voters. In my opinion, UI is not an issue at all. I was advocating better voting systems.

I agree with you that it is better to hold the voting phase on mediawiki.org to avoid fraud.

Tgr added a comment.Jan 19 2017, 6:55 PM

The CommTech Wishlist used approval voting, which is arguably superior to STV. In any case, voting systems are usually analyzed in the context of political elections, not tasklist prioritization, which does not necessarily have the same requirements. The only voting criteria which is obviously important for a wishlist is the independence of irrelevant alternatives and approval vote meets that. So UX and transparency is more important and approval voting is better at those, because voting becomes a lot simpler both conceptually and process-wise when you don't have to deal with preferences.

@Qgil @Tgr Happy to promote the survey to the lists that you both have shared on the topic's page.

I know we want to get the survey out quick, but I've one concern -- right now we are only asking people to propose wishes via Phabricator. If we decide to go with voting on MediaWiki, then I imagine us copy pasting the gathered proposals onto the Developer Wishlist page to make them available for the voting round. Is that right?

Just wanted to make sure, we don't want to add any information to what @Qgil originally sent out to Wikitech-I based on the decisions we make here.

If all sounds good, I will send out the emails tomorrow.

Tgr added a comment.Jan 20 2017, 5:57 AM

If you are referring to a better UI than adding votes to wiki pages, that is a different discussion... I wonder if VisualEditor + copy&paste votes would work. I haven't tried.

There are two ways to hold users' hands: link to section edit with an editintro that provides copy-paste text for a vote, or use a separate subpage for each proposal, use section=new and preload to pregenerate the vote text, and then hope people find back to the main voting page (which is the main usability issue with templates).

Tgr added a comment.Jan 20 2017, 6:03 AM

I know we want to get the survey out quick, but I've one concern -- right now we are only asking people to propose wishes via Phabricator. If we decide to go with voting on MediaWiki, then I imagine us copy pasting the gathered proposals onto the Developer Wishlist page to make them available for the voting round. Is that right?

Yeah, it would certainly be nicer than just linking to Phabricator tickets. (That would mean manual work as the Phabricator markup language is a one-way street that's not supported by any markup conversion tool whatsoever, but so far the amount of proposals is not overwhelming.)

I don't see the need to duplicate information, but we have more days to discuss that. Announcing the survey in more venues is urgent, and the wikitech-l announcement is still valid: proposals need to be submitted in Phabricator.

Hi!

Can you help to solve this problem?

https://phabricator.wikimedia.org/T36193

I am not request you to do your own or by team. If you motivate some programs to do this, many Languages will be benefited. Please help us. Thank you.

4nn1l2 removed a subscriber: 4nn1l2.Jan 21 2017, 1:34 PM

@NehalDaveND: This task is about deciding on the voting process. https://phabricator.wikimedia.org/T36193 is entirely unrelated.

@Qgil I've started triaging the proposals, with some advice from @Tgr! Some of my concerns/ questions to get these proposals ready for the voting round:

  • Most of the proposals were created a long time ago, and thus they are missing an appropriate description. Some of these are proposed by someone else and not the author, so I see recruitng someone from the task subscribers for adding description as a challenge. I’m wondering that unless we’ve volunteer developers willing to help frame the descriptions, it might be too cumbersome to setup up a MediaWiki page for voting as we decided earlier where we manually copy/ paste proposals. A few ideas that I can think of:
    • Batch edit tasks with a general msg asking subscribers to help edit the description to meet a format (description, proposer name, skills required/expertise/ time commitment, any other external resources/ apis/ libraries/ upstream projects, add any relevant project tag that is missing).
    • If we get some good results from above (which I doubt we’ll get in the next three days) we use MW page setup, if not then:
      • May be consider using Phabricator itself for voting just like we did it for the unconference sessions for the summit.
      • Or in the MW page, we just use task title, link the titles with phabricator tickets (and not include description), and provide a space for voting.
  • So far I came across one proposal that is being claimed by a staff member and is already in development mode. Do we need to include such proposals as well in the voting round?
  • Additional thought maybe we also add a status field to proposals: “Need votes”, “In development”, etc and also ask in what capacity would someone (if willing) be able to provide help with the development of a proposal? I think in this context @Tgr mentioned something like Testimonials.

Any thoughts?

  • Or in the MW page, we just use task title, link the titles with phabricator tickets (and not include description), and provide a space for voting.

This is what I was having in mind all along. Only titles and votes in wiki pages, all the rest in Phabricator.

If this would be a survey for users, I would find the requirements for good descriptions to be a must, but beig from developers for developers... I think we can relax a bit. Still, a batch comment to all tasks with weak descriptions is still welcome. I will do my part in the tasks I have proposed.

  • So far I came across one proposal that is being claimed by a staff member and is already in development mode. Do we need to include such proposals as well in the voting round?

Why not.

  • Additional thought maybe we also add a status field to proposals: “Need votes”, “In development”, etc and also ask in what capacity would someone (if willing) be able to provide help with the development of a proposal? I think in this context @Tgr mentioned something like Testimonials.

Mmm.... as you see fit. I personally would not complicate things, but my lazy bias and the tight deadline could be influencing this thought. :)

maybe we also add a status field to proposals

That refers to a mediawiki.org page I assume? If this is about Phab though it sounds like workboard column naming territory to me...

@Qgil Sounds good. @Aklapper yes, the status field was about MW page!

@srishakatux: As https://www.mediawiki.org/wiki/Developer_Wishlist states "Click on a category to vote on proposals", do you want to close this task as resolved?

Thank you so much to @Tgr for leading, designing, and implementing the wonderful voting system :)

srishakatux closed this task as Resolved.Feb 13 2017, 9:35 PM