Talk:Community Tech team/Community Wishlist Survey

Other pages

I suppose this and maybe this (and probably some other pages) will taken into consideration. --Edgars2007 (talk) 13:19, 20 August 2015 (UTC)

The Community Tech project ideas page is a good page to propose and discuss ideas for the survey. We won't automatically be taking suggestions from that page though. They will need to be formally submitted as proposals during the survey. The Technische Wünsche survey is a similar survey to this one, but scoped specifically to the German Wikipedia. The WMDE TCB team is going to be conducting another Technische Wünsche survey around the same time as ours and we are actively coordinating with them to make sure it isn't going to be confusing for the German community. I imagine there will be a fair amount of overlap in the requests, but it will be up to community members whether or not they want to submit requests in both places. Kaldari (talk) 16:49, 24 August 2015 (UTC)

Re: most of them have not been sorted/prioritized

Bugzilla votes did sort requests.[1] --Nemo 08:24, 22 August 2015 (UTC)

That's true, although only a small percentage of community members used bugzilla (and now Phabricator). We looked at the top-voted Bugzilla bugs for our last sprint, but most of them seem to be epic bugs that are too large for our current team to take on anyway. Kaldari (talk) 16:55, 24 August 2015 (UTC)

So it seems there are going to be several filters: epic bugs (and presumably epic new features) are going to be kept off the proposal-list. Next, proposals have to be endorsed, aka pre-voted-upon. Finally, proposals that pass both of the early filters (plus the implicit "zeroth filter" of somebody bothering to make the proposal), will be bangvoted upon in some unspecified fashion. I would suggest that the size-filter be made explicit, instead of having an ad hoc system, where epic-bugs-n-features are kept from being listed, and all the ultra-tiny-low-hanging-fruit-bugs-n-features are mushed in with and conflated together with the large-but-not-quite-epic-bugs-n-features.

  In other words, I suggest the following stages: zeroth stage, proposals are submitted, and none are rejected outright. First phase, proposals are ranked according to "size" aka a rough estimate of developer-effort, ranging from the proverbial EasyFix all the way up to the EpicBug (this size-ranking aka difficulty-ranking can be performed by the WMF devs alone... but methinks it would be better to have some input from e.g. enWiki VPT folks in case any of the size-assignments are controversial or tricksy). Second phase, an initial bangvoting session, with only 'support' and NULL-aka-blank bangvotes allowed, but participants in phase#2 can mark as many meritorious proposals as they wish with 'support'. Those proposals that achieve as least N support-bangvotes in phase#2, will move into the third and final phase. During phase#3, the limited devpower of the WMF team is allocated && prioritized; every bangvoting participant is given (say) a dozen bangpoints, which they can spread amongst the proposals which made the cut, as they see fit. The twelve bangpoints can be allocated to support a total of 12 small-size-bugfixes-or-features, or alternatively, 6 medium-size-improvements, or alternatively, 3 large-size-improvements. The bangvoter can also distribute their bangpoints in more complex fashion: quadbang on a single large-size-bug, dualbang on three medium-sized-bugs, and solobangs on a couple of small-size-bugs.

  I realize this suggestion is probably too complex to be workable; explaining it just to enWiki participants would be difficult, let alone translating it to other languages, and it sounds like the survey will be advertised to first-time-editors, not just to long-term wikipedians. But my main thrust remains, even if the details I suggest are not necessarily the best option: there needs to be a size-ranking, of the proposals. People should not have to choose between bangvoting in favor of a large complex bugfix... or instead casting an equally-weighted bangvote for a small straightforward bugfix. We want to encourage people to bangvote for a dozen small bugfixes, rather than pinning their hopes on a dozen large bugfixes which the team will be unlikely to successfully complete. Along the same lines, the epic bugfix proposals should not simply be swept under the rug; if there is the community will to fix those epic bugs, taking the risk of failure at the epic task in preference to a dozen easy small-size-bugfix mini-projects... well, then so be it. But I strongly suggest that some scheme be worked out, where bangvoting can be tempered by the estimated-technical-difficulty of the proposal on which the participant is bangvoting, so that we encourage people to approve the low-hanging-fruit, rather than bangvoting for the stars and getting disappointed in the end. 75.108.94.227 03:22, 26 August 2015 (UTC)

These are good points. Thanks. We hope to be able to offer feedback on as many of the proposals as we can before voting begins, assessing them for feasibility, risk and impact. /Johan (WMF) (talk) 09:09, 26 August 2015 (UTC)

Voting process

There should probably be a filter, i.e. only proposals with 2? 3? N? endorsements are put up for vote. --Nemo 08:36, 22 August 2015 (UTC)

That's probably a good idea. Kaldari (talk) 16:56, 24 August 2015 (UTC)

I added a requirement that each proposal has to have at least one endorsement. I don't want to set up too many hurdles for folks, but I agree that some filter (even if it is minimal) should help. Kaldari (talk) 02:23, 15 September 2015 (UTC)

Translation

Translation is not trivial. I suggest you ask the help of a WMF person experienced in translation administration to lay out a precise plan. --Nemo 08:36, 22 August 2015 (UTC)

Concerns

I think it is great that in WMF there is a team now that is collecting the needs from the community and turns this in software improvements. This sounds to me as a great improvement.

About the survey I have some thoughts. Concerning the section Outreach, I am not sure how many wikis have such, but there still exist technical ambassadors who serve as an intermediate between the tech and the community. From the tech side the ambassador translates software changes into text with enough contest and clear wording for local users on wikis, and informs the community about software changes and more. From the community side the tech ambassador translates problems, issues, feedback and more to the tech side. For the Dutch wikis I serve as technical ambassador to have the interaction tech-community go more smoothly.

Abouth the sections of Phase 1 & 2 I am concerned. The way it is suggested to be set up now is that the proposals with the most votes win. First of all, large wikis & communities have more people to submit proposals and more people to vote. So it seems that this is becoming a popularity contest, which is the wrong direction. In the Dutch community it happens a lot that users are against certain software, until they tried, and the other way round happens as well. Basing a voting on what people like can easily become unbalanced because of various factors. Also what matters to one person, does not have to matter to another person (like because he doesn't do anything with it), while it can be essential to another.

Also I think that the survey is missing an important factor: what level of importance does a certain software have. This can't be determined by a voting. The determination can vary, but I see three different importancy levels:

1. software that is broken or cause troubles, while it is essential
2. software that is missing and needed to get a core process running
3. software that is helpful, extra, handy, but not part of a core process

That still level ones exist is a piece of past heritage, sadly.

Another subject that recently came up is the subject of continuity. One of the largest announces I notice is that users see that software is no longer maintained, but still like to use it, are getting very annoyed. This is not an issue that is incidental, it is a structural problem.

In general speaking I am happy with the team and the survey, but I think it will need some improvements before it can be used in a balanced way. Romaine (talk) 00:47, 26 August 2015 (UTC)

There could be a multi-level voting where one can vote for one of those three importance levels, but beware of complications. --Nemo 08:24, 26 August 2015 (UTC)

Thanks for your comments and concerns! We do, at the moment, plan do include that in our analysis, which is supposed to be a safeguard against the problems you're describing. There's a difficult balance between making sure we're working on projects that will benefit the broader community, and not putting our wishes ahead of the communities' wishes. If something concerns a lot of people, that's a good sign we need to work on it; we want to focus our work where it has impact. But this is still very much a work in progress, so I'd have been surprised if we'd have stumbled on the perfect process. You think we're not adequately addressing these concerns?

We're trying to address the problem with problem with software that's no longer maintained to some degree (trying to find broken gadgets and fixing them), but Community Tech can't take responsibility for maintaining orphaned or abandoned projects from other WMF teams. That's an issue bigger than this small team. /Johan (WMF) (talk) 09:02, 26 August 2015 (UTC)

more than wikipedias

I hope that the process can be more than a straight popularity contest. If it comes down to popularity the big 10 wikis will get their wishes yet again. I would like to see the scope for progress to include the holistic benefit/value of a proposal for all wikis, or for target audiences.

OR

Some means to identify the wiki sister projects that would benefit from each proposal and to see that some of the love can be spread rather than singularly focused. — billinghurst sDrewth 07:50, 26 August 2015 (UTC)

Agreed. --Nemo 08:24, 26 August 2015 (UTC) P.s.: Again? Only 1 big wiki typically achieves its wishes. :)

We've tried including it in the process ("Impact: How many wiki projects will this benefit?"). Do you fear that won't be enough? Do you have specific suggestions? (Not having specific suggestions doesn't mean we're going to ignore the concerns, of course, I'd like to add.) /Johan (WMF) (talk) 08:32, 26 August 2015 (UTC)

Implicit votes

We should probably also have a system of implicit votes. For instance, if 100 users, who were active in the last 6 months, enabled a gadget which is now broken (cf. phabricator:T108282), that should automatically count as 100 votes for fixing it. Votes should be weighed cross-wiki, for instance if a user is the only active user of a certain wiki then their "vote" for that gadget (which might be essential to the survival of that wiki) should count 5, 10, 25 times the vote of a random user of a random wiki. --Nemo 08:24, 26 August 2015 (UTC)

That sounds like a good task for solving bug T108282, but I think it might make the process for this survey more confusing. Kaldari (talk) 23:35, 8 September 2015 (UTC)

Are we making any progress on this?

I have been watching this page and hoping for a place to make a technical proposal that actually results in some sort of interaction with a WMF developer regarding the merits of the proposal There was a flurry of activity on 26 August 2015, then nothing for the last week. Are we making any progress on this? --Guy Macon (talk) 14:59, 2 September 2015 (UTC)

We're still on track with the roadmap, I think. Last week was slow on this particular front because Kaldari hasn't had internet access, but you should be able to see more progress soon. :) /Johan (WMF) (talk) 00:30, 7 September 2015 (UTC)

@Guy Macon: I'll probably be doing some more work on this page tomorrow (Friday) or Monday to integrate more of the suggestions we've gotten. I was out all last week so it got stalled for a bit. Ryan Kaldari (WMF) (talk) 01:29, 11 September 2015 (UTC)

Including more people in the analysis and prioritization phase

@DannyH (WMF) and Birgit Müller (WMDE): What do you think about the idea of including a board member or community representative to participate in the analysis and prioritization phase? Ryan Kaldari (WMF) (talk) 22:07, 6 October 2015 (UTC)

It depends on what the goal is. More transparency? They might have more ideas or experience that the team doesn't? Just to make sure we don't pull something sneaky? :) If it's more transparency, then I don't know if having an extra person would help; we should focus on getting that information out to more than just a representative. DannyH (WMF) (talk) 22:22, 6 October 2015 (UTC)

Spot the difference

• 
  WMDE Technical Wishes - Collaboration and Communication
• 
  WMF Community Wishlist Survey

Ping pong vs. Marathon? --Atlasowa (talk) 20:10, 14 October 2015 (UTC)

Yet Another False Start

Yet Another False Start towards the WMF actually having some sort of open discussion with the Wikipedia community, then abandoned with no forwarding address in 2015. I'm just saying. --Guy Macon (talk) 02:52, 18 September 2019 (UTC)

@Guy Macon: , what do you mean? The Community Tech team has run four annual Community Wishlist Surveys since 2015, and worked on dozens of projects for the Wikipedia community. Here's the most recent list of projects. -- DannyH (WMF) (talk) 02:59, 18 September 2019 (UTC)

Yes, the WMF has indeed opened other discussions with the community on other pages, and it looks like you have done a good job on those other pages, but on this page (which you will notice is not titled "2015 Community Wishlist Survey") we have the start of a discussion, and then it just ... stops. And it stops leaving phrases like "before voting begins" (no indication on this page where to find the results of that vote), "We're still on track with the roadmap" (the link does not lead the reader tom any sort of roadmap) " I'll probably be doing some more work on this page tomorrow" (and then nothing) and a question from DannyH (WMF) (which would be you) addressed to Ryan Kaldari (WMF) which never got answered.

My point is not that the WMF hasn't done a bunch of other stuff to engage with the community. You clearly have. My point is that along the way you abandoned at least this one page (there may be more) with no closing summary, no obvious links to whatever came next, and no indication that the page was only for 2015. If this had been the English Wikipedia the page would have been summarized, marked as historical, and links added so that if someone found this page (there are many ways to find it:[2][3][4]) they would know where to go to find something that isn't historical. --Guy Macon (talk) 03:56, 18 September 2019 (UTC)

Same team, same project, same year. It just moved to Meta instead of Mediawiki, and continued for the next four years and counting. Not sure what the concern is. -- DannyH (WMF) (talk) 04:01, 18 September 2019 (UTC)

You don't see any problem with a page that users are likely to find be searching, abandoned and moved to meta with no closing summary, no obvious links the meta page and zero indication that the page was only for 2015? No problem at all? Nothing at all you could have dome better?

I give up. Unwatching this page. --Guy Macon (talk) 04:16, 14 October 2019 (UTC)