Enquête over de verlanglijst van de gemeenschap/Beschrijving
Deze page wordt bewaard vanwege historisch belang. Elk genoemd beleid kan achterhaald zijn. Als je het onderwerp nieuw leven wilt inblazen, kun je de overlegpagina gebruiken of een discussie starten op de centrale overlegpagina. |
The Community Tech team is focused on meeting the needs of active Wikimedia editors for improved, expert-focused curation and moderation tools. The creation of the Community Tech team is a direct outcome of requests from core contributors for improved support for moderation tools, bots, and the other features that help the Wikimedia projects succeed.
In november 2015 begon Community Tech met het eerste Enquête over de verlanglijst van de gemeenschap, om te zien welke functies en verbeteringen het belangrijkst zijn voor Wikimedia bewerkers. We nodigden bewerkers van alle Wikimedia projecten uit om voorstellen in te dienen voor het Community Tech team. Na een twee weken lange periode van het verzamelen van voorstellen, vroegen we hen om te stemmen op voorstellen waar ze het meest in geïntereseerd waren. De voorstellen met de meeste stemmen kregen vervolgens de hoogste prioriteit het backlog om onderzocht en aan gewerkt te worden. Dit proces vindt sindsdien elk jaar plaats.
Motivering
We realiseren ons dat er veel bestaande wensenlijsten van de gemeenschap zijn; de meeste daarvan zijn nog niet gesorteerd/geprioriteerd door de gemeenschap, veel zijn verouderd en de meeste hebben geen duidelijke afbakening. Daarnaast zijn we ons niet bewust van technische enquêtes die actief contact zoeken met een groot aantal Wikimedia projecten.
Bereik
The team like to get input from as many editors and as many communities as possible. To accomplish that, we work with the Community Engagement team and the Communications team to formulate an outreach strategy. This strategy may involves blog posts, site notices, talk page invitations, Village Pump notices, mailing list posts, Tech News, IRC, social media and other venues.
Locatie
De enquête zal plaats vinden op Meta. Er zijn meerdere redenen om de enquête op de wiki te houden in plaats van een enquêtehulpmiddeln van een derde partij te gebruiken:
- Bewerkers zijn per definitie het meest comfortabel met wiki's en geven vaak de voorkeur aan de transparantie en flexibiliteit van wiki's over meer gespecializeerde software. De gemeenschap voert enquêtes en peilingen op de wiki uit, zelfs voor relatief complexe peilingen zoals Afbeelding van het jaar.
- Het is makkelijker op wiki's om discussie en stemmen te combineren.
- Vertalingen van voorstellen kunnen eenvoudiger worden behandeld door vrijwilligers als deze op de wiki plaats vinden.
Bereik
Requests should ideally align with the scope of the Community Tech team. In particular, they should be discrete, well-defined tasks that will directly benefit the core community. Tasks that are outside of that scope may be declined or referred to other development teams.
Deelnamevereisten
Om mee te kunnen doen in de enquête (door voorstellen in te dienen, voorstellen te steunen of stemmen) moet de gebruiker een geregistreerd account hebben, met betrouwbare bewerkingen alvorens de enquête begint, of een active Toolforge ontwikkelaar zijn. Iedereen, inclusief anonieme IP gebruikers kunnen meedoen aan de discussie. Bewerkingen op andere wiki's kunnen geverifieerd worden via Special:CentralAuth.
Fase 1: Voorstellen indienen
In de eerste fase van de enquête vragen we naar voorstellen voor technische verzoeken. Er is een limiet van drie voorstellen per persoon. De gemeenschap wordt aangemoedigd om deze voorstellen te organiseren, te be discussiëren en te debatteren tijdens de eerste fase van de enquête. Het Community Tech team kan terugkoppeling bieden over de technische haalbaarheid van het voorstel en of het binnen de scope van het team valt. Een voorstel dat overeenkomt met of tegenstrijdig is aan items van de planning van een ander WMF team kan worden aangemerkt door het Community Tech team om niet meegenomen te worden in de stemfase. Dit kan ook gebeuren met voorstellen die geen technische verzoeken zijn, maar bijvoorbeeld beleidsdisucssies, voorstellen waarvan we weten dat ze niet uitvoerbaar zijn of voorstellen die simpelweg niet begrijpen en waarvan de voorsteller niet reageert op verzoeken voor verduidelijking.
Hoewel het grootste deel van dit proces in het Engels plaats vindt, nodigen we eenieder van elke Wikimedia project uit om voorstellen in te dienen. We zullen vrijwillige vertalers vragen voorstellen naar het Engels te vertalen.
Indeling van de voorstellen
Voorstellen kunnen ingediend worden in elke taal, maar Engels is aanbevolen (om de terugkoppeling van het Community Tech team en andere bewerkers mogelijk te maken). Idealiter bespreekt uw voorstel de volgende punten:
- Wat is het op te lossen probleem?
- Welke gebruikers hebben hier voordeel van? (bewerkers, moderators, gebruikers van Commons, gebruikers van Wikipedia, enz.)
- Hoe wordt het probleem nu aangepakt?
- Wat zijn de voorgestelde oplossingen (als er ideeën zijn)
- Zijn er relevante Phabricator taken?
Fase 2: Voorstellen beoordelen en organiseren
Tijdens de tweede fase gaan de Community Tech en Technische Samenwerking teams door voorstellen. We organiseren ze, vragen om verduidelijking, voegen duplicaten samen en proberen de voorstellen zo goed mogelijk te maken zodat de bewerkers weten waarvoor ze stemmen en dat het voorstel duidelijk uitlegt wat de voordelen zijn. Sommige voorstellen die niet haalbaar zijn of niet technisch zijn worden gearchiveerd.
Fase 3: Stemmen
Tijdens de stemfase kunnen bewerkers stemmen op de voorstellen waarvan ze willen dat het Community Tech team aan gaat werken. Stemmen voor die gemarkeerd zijn met Support en een handtekening worden meegeteld. Reacties gemarkeerd als Neutraal of Tegen zijn acceptabel, om te vragen voor verduidelijking of om potentiële problemen te identificeren, maar ze worden niet geteld als stemmen tegen.
Wanneer de stemfase is afgelopen zal een volledige lijst met alle voorstellen worden gekopieërd naar een nieuwe wikipagina, samen met de uiteindelijke stemresultaten.
Analyse en priorisatie
We've developed a method to help us approach our wish prioritization more systematically and with transparency over the years. There were a few assumptions built into our prioritization process which are helpful to name explicitly:
- Popularity of a wish should be a very important factor in our selection decision, but not the only one.
- It is best to stagger wishes so that specialists can collaborate with each other as we progress through work-- i.e. as the designer researches the wish and generates visual components for wish, the engineers focus on a wish that is purely technical.
- It is best to communicate transparently with the communities rather than hiding the details. Visibility builds trust and dialogue.
The process consists of going through any wish that scores in the top 30 for a wishlist (we cut off any wishes below that, because realistically, it takes time to investigate every wish and we know we will not be able to grant more wishes for a given year) and scores them based on the following criteria:
Once every wish is scored from every vantage point that impacts its feasibility and impact, we rank them. If we tackle those wishes first, we can tackle most wishes. Also, we can optimize for impact while taking maintenance and complexity into account.
This also means talking to other teams at the Foundation, and investigating if they were already working on projects related to wishes.
Ontwikkeling
As each request advances through the development process, its status will be updated on the wiki page allowing the community to easily monitor the team’s progress and offer feedback.
We also work on some requests that didn't perform well in the overall leaderboard but are still very relevant to smaller projects, though our main focus will be on the global leaderboard.