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. --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)

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)

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)