Community Liaisons/Process ideas

We're inviting users to brainstorm ideas to improve how software components get built and delivered to communities.

  • How can communities be more involved, and how do we include a broader range of voices?
  • How do we use the tools we already have to include and involve communities?
  • What new tools and processes should we look at?

Use the Discussion page as usual, while we collaborate on a single, coherent document (no commentary). Please use a neutral point of view -NPOV- and assume good faith. This is an important topic and we want to be able to consider ideas, and those three things will help.

Current state

  • A change – from creation of an entire product to a styling change on a button – is selected for development. The idea can originate from Wikimedia Foundation senior management, the appropriate area's product manager, groups of interested staff developers and/or designers, individual staff developers and/or designers, volunteer developers, or several other sources.


  • Major products (e.g. VisualEditor) may have one or more assigned community liaisons who will work with the development team and communicate feedback between the community and the development team.
  • Feedback that the product is unwanted or on the wrong track is often filtered out as non-actionable. This applies to surveys, community liaisons, and "Community Consultations".
  • For some features, the Beta Features system is used to solicit early feedback they are moved into production; each Beta Feature has an associated discussion page. Beta Features are announced in a variety of channels, including in a post to the Wikitech Ambassadors mailing list, on the Wikimedia blog, and through the Tech News newsletter.
  • Before bigger changes roll out to production, announcements are often posted through a number of channels, including individual wikis' village pumps and the Tech News newsletter. The members of the Wikitech Ambassadors mailing list are sometimes asked to help, especially if a rollout requires on-wiki coordination.


  • Progressive rollouts (per wiki) are used for all normal changes which follow the standard deployments: the first wiki to receive new software is and the change does not affect all production systems at once. Significant software changes may be spread over a period of days, weeks, or months, in a custom deployment order for every product, depending on expected server load, language support, local interest and other factors.
  • As for "big" feature development: one process in use is Beta Features; many other products (e.g. AFT, MoodBar, PageTriage, Echo, Flow) are deployed on the English Wikipedia as first content project; some other products spent most development time in collaboration with wikis which volunteered by consensus to pioneer, for instance Wikidata and CirrusSearch. English Wikipedia is also a tool or target of various ad hoc initiatives like experiments, gadgets (e.g. GettingStarted tutorials, Teahouse, AFC stuff) and maintenance of community-owned spaces (like local "Wikipedia", "Help", "Template" and "MediaWiki" namespaces, mainly for documentation or scripts).
  • Progressive rollouts per user (1% of users at a given wiki receive access to a new product, then 5%, then 10%, etc.) have so far been used only for HHVM (2014). Some preferences defaults have been changed for future accounts only.

Requested changes


Some changes are discussed by communities before and/or after the deployment. After deployments, community discussions sometimes result in a request for a configuration change to default-off for software, or to have the software disabled completely. Configuration changes are normally based on consensus.

  • The WMF reserves the right to refuse any requested change, and has invoked this claimed right.
  • Both before and after deployment, community members have no way of knowing whether the WMF will follow the apparent local consensus (as they did, e.g., with AFT and VisualEditor), or will not follow local consensus (as they did not, e.g., with ACTRIAL and Media Viewer).
  • When reasonable requests are refused (whether to install software, re-configure software, or remove software), community members may feel insulted and disrespected, as happened with the forceful deployment of Media Viewer at the German and English Wikipedia.

Gaps in the process

  • Major projects may be initiated with no community buy-in, i.e. without determining whether the community wants a product, or whether a project is going a direction acceptable to the community.
  • Clear goals for success on features are not always fully defined.
  • Once a project has been initiated by WMF there seems to be no ability to accept input that a project should be halted or fundamentally change direction.
  • There is no defined, effective culture of prototyping features and getting early community feedback.
    • Software is under active development during Beta phases, causing mismatches in expectations. What you tested 2 months ago, might be completely changed when released today
    • Actual deploy can occur before all feedback and bugs of Beta phase have been (or can be) dealt with
    • There is no incremental opt-in, opt-out, full path to roll-out
  • Actual deployment results in finding bugs that were not encountered before, either due to load, workflows not encountered during testing.
  • There is no single or centralized place for all product communication. Venues of notification are highly susceptible to information overload
  • There's no consistent notification mechanism for major releases that actually reaches all active users; Echo currently doesn't have the required functionality, see bug 51540.
  • Surveys are voluntary and thus highly susceptible to voluntary response bias.
  • The step from the smallest wikis to the largest ones (English/German WP) is still pretty large, and this is where conflicts occur most frequently
  • The complexity of the largest wikis and their communities, and thus their software needs, is not easily reproduced outside of these communities.
  • Votes/RFCs tend to only reach a small subset of the active users and can be perceived as not representing readers directly. The "silent majority" often has users who will speak for them, but without hearing from them directly, it's hard to know exactly what their experience would be.
  • Votes/RFCs are often underway while a feature is undergoing active development; issues that are being raised may be fixed during the process. Time/complexity estimates for needed improvements are sometimes not taken into account.
  • The reasons given by participants Votes/RFCs are not carefully considered. If the reason for an individual vote is not an actionable bug to fix, or is not an actionable feature request, then further development is unlikely to alter that vote. If a majority of votes are non-actionable objections then continued development is likely to face permanent community rejection.
  • There's no fully agreed upon social contract between Wikimedia Foundation and the community at large as to how/when it will respond to RFCs/votes. Wikimedia Foundation states it reserves the right to make its own decisions on a case-by-case basis; many community members feel Wikimedia Foundation needs to respect and implement community process decisions when they do not conflict with legal, financial, technical, or core mission concerns. This different perspective can lead to escalation of conflicts involving crude hacks implemented in the MediaWiki: namespace to disable features, and crude hacks to core Wikipedia software to disable community editing. Such hacks tend to be faulty, either disabling a feature rather than setting it to opt-in, or allowing a user to delete and recreate a protected page to reenable editing.
  • There is not a clear understanding of the role of volunteer developers and the relationship of the work they do to WMF plans.
  • There is no mechanism to set a context for volunteer effort to ensure that it is coordinated, relevant in WMF plans or user aspirations.
  • There is not enough proactive engagement with specialist communities to understand the special needs they might have, and how they cut across projects.
  • There is no obvious universally visible and agreed chart of dependencies in the various products to prevent changes in one thing breaking another.
  • There is no "one-stop shop" for users requirements, volunteer offers and WMF planning to intersect.
    • There's no regular touchpoint with the community to discuss and prioritize user-facing improvements in general
    • There's no ongoing "high touch" participation of deep subject-matter experts from the community in the product development process. Liaison work tends to be more transactional in nature.

Process ideas


Prioritization process



  • Communicating specifically about prioritization, resources and problems which need solving to increase understanding about product priorities.
  • Data and research can help to guide decisions. Community understanding around long-term and short-term goals helps to bring in new perspective and increase understanding around decision-making and prioritization.
  • A public backlog showing product and feature ideas which are accepted and where they sit in the priorities.
  • A way for the community to influence what projects get investment and when. If it works, an opportunity to deal with more of the "low hanging fruit" and not waste effort on projects that are unlikely to make a meaningful return on the resources required.
  • Require real community buy-in before initiating projects that are large or potentially controversial.

Advantages of Inclusion in Prioritization

  • Gaining consensus on product development priorities.
  • Transparency of data.
  • Does address one of the root issues of the problem - a lot of internal communication making hard for people to get involved (another issue being weak communication of the free software concept to end users).

Disadvantages of Inclusion in Prioritization

  • Different groups have different priorities and perceptions of the most important problems to work on.
  • Lack of resources (or, in some cases, will or discipline) to ensure that foundational infrastructure improvement/upgrading/modification is carried out before trying to address "priorities", leading to unsuccessful or only marginally successful deployment of priority projects.

Technology Committee




Advantages of the Technology Committee

  • Provides representation of multiple kinds of stakeholders
  • Provides opportunity for in-depth engagement by and with Committee members about technical issues
  • Is less costly and less time-consuming than a project fork
  • Enforces technical evidence-based communication all the way up

Disadvantages of Technology Committee

  • Longer process for making decisions about product rollouts
  • Elections of Committee members require a time investment
  • Formalises the notion that stategic leadership at Board level does not require technical expertise
  • Does not address the root issues of the problem - a lot of internal communication making hard for people to get involved & weak communication of the free software concept to end users - directly. (Does have a potential to address them indirectly, but only through resolving other problems listed on this page.)

Product Life and Community Engagement Milestones



  • Require real community buy-in before initiating projects that are large or potentially controversial.
  • A continuous feedback loop of planning and discussion around planning in different stages of the product lifecycle: problem identification, planning/development, testing, deployment, lessons learned.
  • (One option): Regularly scheduled live conversations on IRC/Google Hangout/something for each product team that are open to everyone in the community. Maybe once or twice a month, in a couple of different times to accommodate different time zones. The meetings could include a brief overview of the project's progress, with lots of time for questions and answers on all sides.

Advantages of Engagement Milestones

  • Obtaining real community buy-in before initiating projects that are large or potentially controversial addresses the risk of allocating resources to a project which is fundamentally on the wrong track and which may face permanent community rejection regardless of improvements.
  • (for scheduled live conversations): More transparency for the community about the project's goals and progress. An opportunity for the project team and interested community members to talk about problems and solutions, come up with ideas and check assumptions.

Disadvantages of Engagement Milestones

  • (for scheduled live conversations): Lots of time zones -- some people are only available during the workday, some only at night or on the weekend. No matter what, somebody will be left out. Everyone needs to be dedicated to making it a positive, productive process, not an opportunity to flame or troll.
  • Does not reach 99.9% of userbase -- those small "meetings" are really a poor practice and are a participation barrier even for active editors. Decisions get made internally, and, even with note-taking, processing results of a meeting is a tiresome process. (With the currently detailed What as of August 22, 2014.)
  • Implies that some tasks remain internal and community is only engaged at discrete stages of product development. While calls for participation are a good idea, I would prefer to abandon internal communication and decision-making entirely.

Incremental and Staged Rollouts



  • How do we include communities in deciding which wikis/sections of communities to roll out to?

Advantages of Staged Rollouts

  • It reduces the costs of both deployments and the revocation of deployments.
  • It allows a community to be gradually familiarised with a product, as it's being developed, and give feedback while the product is in development.

Disadvantages of Staged Rollouts

  • Disjunction might create confusion between user groups ("I see this, he sees that"). Additionally might burden support (technical and community).
  • This idea, implemented alone, does not reach 99% of userbase.
  • I feel this idea is of low priority. A well-engaged community throughout the entire product life-cycle, not only its rollout (which may or may not happen, depending on how the local wikis like the product), is more important.

Notifications for Beta Features / More deliberate notifications


What (Beta Features)

  • All users get notified each time a new Beta Feature is available, so they can try them out, make suggestions, highlight issues, and give other feedback
  • All users get notified in advance each time an existing Beta Feature "graduates" to be on for all users, so they can give last-minute feedback and for awareness
  • Users can opt out of these notifications if they aren't interested, but by default they're available to all for maximum feedback opportunities and awareness
  • 2 potential specs at mw:Beta Features/New Feature Popup Guider and mw:Beta Features/Echo notifications

  • Perhaps we don't want to nag people about new beta features. They'd disable notifications with a "wth is this? I'm not tech-savvy" and never see them again.
  • Instead of notifications, it could simply say the dates (when was it added to beta?) in the beta tab (and a new! red note perhaps).
  • Or perhaps mention very very short summary of such recent news in the sidebar.

  • This (and the beta tab itself) should be available to unregistered contributors too.

  • Information about changes would be served to users, rather than needing to be found by users. There are several ways to notify users of changes, from Notifications to new features like pop-ups.
  • Centralizing communications allows the WMF or volunteer development projects to inform users of changes whether at once or on a project per project basis

Advantages of Notifications for Beta Features

  • Notify users of up-and-coming features, clarifying that the feature is incomplete and testing/feedback is requested
  • Even if a user does not want to test or give feedback, they are made aware that there is such a feature/system/product in the works
  • Users can opt out of these notifications if they really don't care about such things

  • Proactively reaching users about changes helps communities to feel prepared for change or invited to participate in collaborate when notified of a beta feature launch or a "last chance to give feedback before deployment."
  • Reduces need for users to go find information; brings information to communities

Disadvantages of Notifications for Beta Features

  • Could be very spammy for low-stickiness users unless the notifications time out even if unread at some point (so you don't come back after 2 months away to find 12 notifications about software changes)
  • Would be very spammy unless implemented as a proper cross-wiki notification type (so you don't get the notification on French Wikiversity, then on French Wikiquote, then on Dutch Wikipedia, then…)
  • We currently can't do notifications for logged-out users (readers or editors), as the Notifications system doesn't support that
  • Only works for code we can split off into Beta Features; not really possible for wider-reaching features like Flow (pages can opt in, users can't) or
  • If implemented with nagging/popups/noise, people would close this off and get rid of this, and remain unaware of future changes.

  • Could become noise if the same systems that notify users of other events are used
  • Could become annoying as in "one more notification system"

Per-project community workgroups



  • Communities would be invited to nominate workgroups of 3-7 representative users to work closely with product and engineering teams, to guide planning, development and release of major user-facing software products.
  • Workgroups would meet regularly with Wikimedia Foundation teams to discuss a range of topics, such as: product goals and target users, work in progress, user data and feedback, and priorities for key features prior to release.
  • Each workgroup would be selected by a process to be determined by the community. Ideally, the group would represent a range of views for the particular project area, as well as have familiarity/expertise in the project area. Proposal for other team norms: participate constructively, empathy for all users, open-minded and data-informed, preferably fluent in English, available to work several hours a week if needed, during Wikimedia Foundation office hours if possible.

Advantages of Community Workgroups

  • Engaging users across different communities can bring differing concerns for representation.
  • Involving community members in the product development process can provide a deeper understanding of contributor needs.
  • Working closely with product teams gives community members a better sense of the challenges and trade-offs for each product.
  • Building relationships with product managers, designers and developers early on encourages a more collaborative partnership.

Disadvantages of Community Workgroups

  • Requires a serious commitment of time for the community members serving on the workgroup.
  • Adds a layer of bureaucracy which may not necessarily be helpful.
  • If binding, will lead to further conflict. If non-binding, not necessarily any different from the status quo.
    • It is implausible that the WMF would accept that it would be bound by any community workgroup. A suggestion that a workgroup would be binding upon the community and non-binding upon the WMF merely gives the WMF two bites at the apple to ignore community consensus. If a majority of the Workgroup disagrees with community consensus then the WMF can place blame on the Workgroup. If a majority of the Workgroup disagrees with the WMF then the we are back at the status quo. Such a workgroup would merely serve as scapegoats.
  • Disputes may arise within a workgroup, which could make the relationship less efficient than we might hope.
  • The selection process could cause some users to feel poorly represented.
  • Vital workflows could still be missed.
  • The community may simply not support this idea, given that it effectively means (on a per-editor basis) that they will get less attention than they do now.
  • It does not necessarily do anything to increase the signal:noise ratio of interactions, it merely reduces the number of interactions.
  • Workgroups would meet regularly with Wikimedia Foundation teams — would you like a rant here?
Please stop communicating things and making decisions internally. Seriously.
  • Does not reach the 99% of userbase. (only reaches contributors who actively communicate with each-other or read the village pumps -- a minority)


Tracked in Phabricator:
Task T89970
Example 1 of a microsurvey
Do you want to try out the
new Example feature?

Yes  No

About this question

Example 2 of a microsurvey
Would you recommend editing
to your friends and family?

Yes Maybe No

I do not want to answer.

What (Microsurveys)

  • Ongoing, brief, onwiki survey asking brief satisfaction questions. The goal would be to to proactively ask a wide range of users about their experience, as a lightweight means of gathering sentiment about particular products
  • These would be 1-2 question surveys with yes/no or other very simple responses, and a very high level, lightweight way to understand sentiment of any product/feature/system which feedback is being generated for.

Advantages of Microsurveys

  • Getting a wider possible range of voices by asking all users for their opinion on a rolling basis.
  • Reaches representative sample of entire userbase, rather than only devs, admins, or established editors.
  • Can monitor for take up and make demographic adjustments related to whole readership. (Geocodeing, edu, com, for example - maybe ask 1 demographic question.)
  • One or two questions, 100% on screen now. No risk that "Would you answer a few questions" will lead to an enormous, time-killing survey.
  • Having 100% of questions on screen now, and simple, quick response options, reduces (but does not eliminate) the risk of self-selection bias by increasing the likelihood of a response.
  • Limiting it to one or two simple questions, with no free-form text responses permitted, makes answering it very quick and simple.

Disadvantages of Microsurveys

  • Normal change aversion patterns show that the initial reaction to a new thing is often negative; any mechanism that ties deployment/rollouts to survey results probably needs to take that pattern into account.
  • Large surveys are hard to do right. (However, this is not a large survey.)
  • Limited scope and space means that the survey contains nothing except the questions at hand, e.g., nothing about how to be involved in product design or development, where to get technical support help, what the local policies are, etc.
  • There is a risk of confirmation bias when surveys are internally produced and internally analyzed as part of project advancement, especially if they contain free-form text boxes. However, microsurveys do not collect free-form text that needs to be interpreted or analyzed – just simple answers.

User Testing


What (User Testing)

  • AB
  • Automated
  • Prototype (observed) by invitation

Advantages of User Testing

  • Provides objective data to justify a decision (or the rolling back of a decision), rather than opinion.
  • User testing can be fast and lightweight with the right protocols.

Disadvantages of User Testing

  • Many "observed" test situations that have been used in the past have had conscious or unconscious biases built into them.
  • Tendency to rely on "observed" or other testing scenarios that are out of date. We have had recent changes based on usability testing done pre-Vector implementation (!)
  • Small number of testers for some types of testing scenarios
  • Testing methods are almost always biased toward certain types of users
  • Contributors are not made aware that they're allowed to be involved in product design or development.
  • Possibly hard to do right - are the results easy to misinterpret?
  • As we found during the initial testing of V/E, disadvantages to the testers are that when things are implemented despite you warning that they are too buggy to rollout, you will be blamed for not spotting those same obvious bugs.

Community Ambassadors and Liaisons


What (Community Ambassadors and Liaisons)

  • A place where community ambassadors and liaisons, developers and Wikimedia Foundation staff have a central place where they can exchange information. If a community (member) has a question, the ambassador/liaison can deliver it to the right person and return with answers. If developers have a new product that they want to test, they can contact the ambassadors/liaisons for helping out with setting it up and returning the feedback back to the developers. If other Wikimedia Foundation staff have questions/issues they want to communicate they can easily reach out to the community this way.
  • A larger community can have multiple local ambassadors to make sure the whole community is covered.
  • ...

Advantages of Community Ambassadors and Liaisons

  • A local ambassador/liaison understands the local language, understands the needs of the community, and can translate the abstract or technical communication to the community in a language that fits better.
  • Working more closely with the community.
  • Wikimedia Foundation can reach out towards to community on their own wiki.
  • Ambassadors and liaisons can signal issues in the community better and communicate them in an early stage to Wikimedia Foundation.
  • Ambassadors and liaisons can help collect feedback from users who express the feedback in their own language on their local wiki.

Disadvantages of Community Ambassadors and Liaisons

  • Requires a serious commitment of all members.
  • Finding the right participants can be difficult. An open attitude and wide understanding is recommended.
  • Currently, many "tech-ambassadors" (i.e., subscribers to that mailing list) are subscribed for their own information because it's one of the few places to find out about certain roll-outs; they did not subscribe with the intention to share information within their own project(s)
  • Can disenfranchise project sites with small active communities whose members (a) do not read English (b) are focused on content creation/routine site administration (c) do not have sufficient technical expertise to understand how changes will affect their day-to-day workload
  • Individuals who are the messengers can be perceived to be/are accused of being quislings who support the Wikimedia Foundation instead of the local community. This has happened on many occasions.

Encourage users to write specs


What (Specs)

  • People should be encouraged to take notes and leave feedback about what routine tasks they perform and find laborious or worth improvement.
  • End users and editors should be able to easily find where to write software specs and take notes of what they need.

Advantages of Encouraging specs

  • Captures the needs of Wikimedia projects at ease
  • No Team would be able to see the entire spectrum of needs of the various Wikimedia project (only if it's psychic)
  • Encourages collaboration on product ideas and design
  • You share the responsibility

Disadvantages of Encouraging specs

  • Despite the community driving the process, the end result may not meet their actual needs. Pending Changes on enwiki is sometimes given as an example of this. Design by committee ....
  • Many users are not conversant in "technicalese" and, even if they have good ideas, will be hesitant to participate.
  • Reflects the wishes of those most highly determined to have a feature created, even if those users are unlikely to actively use or be the "target market" of the feature. Draft namespace is an example of this.
  • Significant amount of work: can we find the volunteers willing to invest for a longer period this much time ?

Make feedback easy in general


What (Feedback)

  • I'd ideally see a "Feedback" link to it in the personal menu of every contributor, registered or not, which would let him/her leave a message about a specific project, page, or its software.
  • Software radio would leave a msg at tech village pump.
  • Thoughts about software from across village pumps should be somehow monitored.

Advantages of Easy Feedback

  • Gets the ideas from everyone in raw shape
  • Available for the entire userbase.

Disadvantages of Easy Feedback

  • Just talk pages are not very collaborative, essays / pages could be better
  • Such feedback often has a very low signal-to-noise ratio; consider the article feedback tool.
  • Feedback requires acknowledgement of reception ('I don't know if my feedback was read by those who need to read it'). This is a lot of overhead with our current systems...
  • Requires moderation and increases community workload if comments are publicly accessible on-wiki.
  • Feedback that does not easily fit into the WMF's plans is dropped unless it is backed by organized community action.

Write (some of) software in wiki markup


What (Wiki Markup)


The last mailing list post said: > The community leads in the development of content; the Wikimedia Foundation leads in the development of technology. -[1] This is contradictory to this page name as well as MediaWiki history. MediaWiki is free software. I wouldn't like it to be developed through a process which consciously isolates development to a given team. Developing free software in teams is against the core of the free software philosophy itself.

  • Writing software should be a hobby, like writing articles.
  • There should be an infrastructure in place to allow people to write small gadgets or widgets to customise the layout and features of the software to suit their needs.
  • This is perhaps done via user-scripts now, but I would like to see it doable through wiki markup. Most people who edit articles know wiki markup, but not many know JavaScript at all. (Besides, many common idioms and tasks which gadgets need are not encapsulated properly; more on this in the next section).
  • Some lots of article wizards and tools which don't modify DOM (like adding a toolbar button) would be able to be written using wiki markup.

Advantages of Wiki Markup

  • Gives a lot of people ability to participate in "software" (on-wiki things) development without learning a new language.
  • This relates to the concept of a continuous path of user self-advancement through seeing wiki markup that others have written, as described here.
  • For developing wizards/software to capture community expertise and pass it on to others, the community members are the ones who have the expertise, so it's far more efficient to empower them to express it directly than to require them to go through a slow and cumbersome process of describing it to someone else who then has to try to understand and implement (and possibly not get it quite right the first time, with further delays and further efforts by all concerned).
  • Wiki markup is not Turing complete. It has limitations built into it, alas some of them complex and/or blatant, but often simple and structural, that make various kinds of Turing-computation-related errors impossible to commit.
  • Wiki markup is, in its basic forms, very simple to use. That's what made it successful in the first place, and is a big part of the reason we're all here. Augmentations would need to be carefully designed to minimize the explosions of complexity that can characterize use of a simple language for things that it can't handle gracefully (such as the baroque templates that motivated the introduction of Lua).
  • An instance of wiki markup augmentation of this type (through javascript and Lua) is already actively under development, described here.
  • Something that, once deployed, would engage the entire userbase by merely existing here and there (like templates do).

Disadvantages of Wiki Markup

  • Wikitext is a markup language, not a programming language, and lacks almost all features of the latter.
  • Not all tasks can be done, ie toolbar buttons can't be done this way. This doesn't mean we shouldn't have some tasks done using markup, though.
  • Some thought would need to go into making sure building a wizard/software would also produce a human-readable description of how things are done, so that a human user (perhaps an admin) would know how to fix the actions of a wizard if it did things wrong or incompletely, or went off-line for whatever reason.
    • Hm? Documentation (and learning) are needed for any software. Is there really a maintainance burden/disadvantage bigger than that JS and PHP software involves?
  • If wiki markup augmentations are made piecemeal/haphazardly to enable functionality, they can result in very messy expression that discourages common users. This seems to have happened, historically, with templates and magic words. Augmentations would need to be designed with an eye to systemic promotion of simple expression.
  • Currently, code and systems (templates and bots and categories) have to be replicated at each project and language separately. However, there are ideas at Global-Wiki (and linked pages) for a more global-template system. There are also ideas for enabling locally-created workflow systems using shared modular actions within the Flow system.

Engage unregistered users


What (unregistered users)

  • Make BetaFeatures available to unregistered contributors.

Advantages of Beta, Unregistered Users

  • Captures the thoughts of the wonderful massive amount of unregistered contributors and readers.
  • Reaches 99% of userbase.

Disadvantages of Beta, Unregistered Users

  • Gets dumped onto ugly awkward talk pages which someone needs to process.
  • Structured feedback could be better.

Introduce structured feedback tools


What (Structured Feedback)

  • Like surveymonkey
  • On-wiki
  • People see all threads
  • Previously discussed here
  • Something in middle of Flow and current talk pages - conversations should be easy to refactor and they should be compact

Advantages (Structured Feedback)

  • Eases the need of processing the mess most RfCs are
  • Empowers local sysops with a tool that gives results consistent (hopefully!) with survey findings of the Engineering teams
  • Empowers local wiki communities with feedback means
  • Affects, indirectly, the entire userbase -- feedback of anyone would get shoved into a corner where it would be read and evaluated properly.

Disadvantages (Structured Feedback)

  • Surveys are very hard to do right
  • Surveys can be manipulated
  • Survey results can easily be misinterpreted, either by mistake, or to reach goals maliciously
  • Requires moderation and increases community workload if comments are publicly accessible on-wiki.

Beta feature ratings



  • Allow users of a beta feature to indicate whether they consider it (a) useful, (b) a good idea but not ready yet, or (c) not useful.
  • Provide developers statistics of how many people used the feature and their general impression. Statistics can be queried in time, product version, project/language, type of user...

Advantages of beta feature ratings

  • Provides an overview of beta feature reception that can include the broad community (combined with beta feature notifications and access to anonymous users to them) and informs next steps.
  • More detailed quantitative metrics for beta features that what we currently have. Current activation numbers include both users that are happy with a feature and those that are not but keep the beta feature to keep track of the development.
  • Could be an entry point for encouraging more detail feedback by asking users about more details.
  • Has a potential to reach the entire userbase, if unregistered contributors are given access to beta features.

Disadvantages beta feature ratings

  • It will reach as many users as beta features do (i.e., if beta features are not accessed by anonymous users, the picture will not be complete).
  • Results be affected by initial impressions and aversion to change.
  • Gives very high level results. It doesn't result in much feedback or insight into why people do/think/say things.
  • Very hard to do right -- high chance of introducing bias by mistake. Needs to be kept very simple, only one (2 at worst) 5-star lines, don't do microsurveys please. :-)
  • With current software, only reaches logged in contributors.
  • There could be privacy implications depending upon granularity of the search terms for output data.

Expose more settings to the community



  • Allow the setting of more MediaWiki variables via special pages. Restrict this to a trusted subset of the community (bureaucrats maybe). Configurable variables must be vetted for performance and security problems.
  • Allow the enabling, disabling and configuring of extensions via special pages. Extensions appearing on these lists may come from a variety of sources, but all must be vetted for performance and security problems.
  • Work in process here at bugzilla.

Advantages (expose more settings)

  • No more silly JavaScript hacks.
  • Devolution allows solutions that are more specific to a given project.
  • Allows bold, revert, discuss to be applied for software decisions.
  • Reduces overhead.

Disadvantages (expose more settings)

  • Increases potential for breakage and edit warring if handed out liberally or without sufficient due diligence.
  • Potentially increases divergence in software settings between projects, increasing burden on maintenance and support
  • Increases likelihood of "silly javascript hacks" because so few members of the community have the necessary technical expertise to write more complex coding. Particularly true for smaller projects, where there may only be one or two people who understand the MediaWiki interface sufficiently to "manage" it, opening the project up to fairly serious divergence from the norm or violation of core WMF policies.

Abandon internal communication


What/How? (Abandon internal communication)

  • Abandon Google Hangouts or any alternatives. Even if you upload the entire video, it's harder for most people to process it than a written message.
  • Stop using internal meetings.
  • Start using and a bug tracker (and gerrit and git, which you are already using anyway) for everything — these two are something people can see, subscribe to a feed of, and participate in.
  • Where an internal communication happens, do note-taking thoroughly and post it to Feel responsible for doing this. (What if two random tech persons were leading a volunteer project and suddenly decided to redesign? They'll have hard times doing so if they don't take notes of all points discussed and don't explain what they did.)
  • Even when doing note-taking about such internal communication, publish it in a shape which encourages community feedback. Nothing should be final.
  • Only use private mailing lists for sensitive communication.

Advantages (of Abandon internal communication)

  • Transparency.
  • Possibility of more engagement of community.

Disadvantages (of Abandon internal communication)

  • Probably impossible to actually implement, since "talking to someone who happens to be in the same office" is an internal communication.
  • MediaWiki is not as useful as ether pad for note taking
  • Agora meetings are not always as useful as table meetings
  • Information overload would lead to claims that the information was "on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'."[ref]

Get local consensus for your changes


What/How? (Local consensus)

  • Use village pump to propose major new projects, potentially controversial smaller developments, and nontrivial configuration setting changes, similarly to how any volunteer peasant would do this.
  • Notifications "Hi, we're letting you know that this will be live" are common but are not proposals.
  • 4. Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by the Wikimedia Foundation, in full consultation with the community consensus. --Statement of principles, Jimbo Wales, 2001 (!; link to the 2011 version).

Advantages (Local consensus)

  • Avoids embarking on projects that the community doesn't want and will not accept.
  • Minority grumbling will be greatly subdued by shared responsibility and the legitimacy added by community process.
  • Transparency.
  • Ability of community to reject new extension or config change, or to accept it conditionally.
  • the community gets empowered
  • opportunity to listen to objections and change plans accordingly
  • Where maintenance and support costs argue for consistency, local consensuses results can be pooled and shared in developing a global consensus on which configuration should be globally applied.

Disadvantages (Local consensus)

  • The average pace is about 500 changes a week, or 300/month for configuration...
    • Common sense can largely resolves this. An obscure bugfix can simply be implemented. A massive project like Flow clearly requires advance community buy-in to avoid setting off in the wrong direction and wasting massive development resources.
    • Those probably need to at least be documented at the affected Wikis in the relevant language.
    • The huge volume may be remedied by figuring out which configuration changes are more essential, or requesting feedback in batches (?).
      • This isn't a binary off or on switch. We could get consensus based on the severity of the change or other factor. Just because its unreasonable to get consensus for every change, doesn't make it unreasonable to get consensus for important changes. As it stands, most controversial changes end up being deployed to a single wiki first. Requiring consensus for any change that would only go out to a subset of wikis (This is especially true of new extension deployments), would be a good first step imo. Bawolff (talk) 16:49, 22 August 2014 (UTC)[reply]
  • Such announcements have historically gotten little feedback, only for people to object after the fact. For example, this versus this and this and this.
  • Potentially increases divergence in software settings between projects, increasing burden on maintenance and support.

Rely on volunteers



  • Expose the roadmap, plans and rough estimates of FTE required
  • Expose the WMF staff strengths, weaknesses and opportunities for external effort
  • Agree a context and a division of labour

Advantages (of Rely on volunteers)

  • Access to a huge pool of enthusiastic, highly motivated workers with a huge diversity of expertise and specialism
  • Force multiplier, can make otherwise impossible projects possible
  • A valuable potential recruitment stream, moving selected workers towards formal contracts or employment
  • Great track record for open source projects such as Linux
  • Mature understanding in the OS community of the culture around volunteer projects
  • Cheap!

Disadvantages (of Rely on volunteers)

  • Reliability: will volunteers do the work, will it be up to standard
  • Novel management challenges for hybrid paid/unpaid workers
  • Culuture shock for both sides may derail projects
  • Volunteers are the most expensive workers you'll ever have
  • Retention may suffer due to day-job/other life requirements.

ED for a day



  • Select a random member of the community, say, from those logged on at a random time on a random day
  • Fly them to WMF HQ
  • Allow them to shadow the ED on a typical -- or possibly, non-typical but interesting -- day
  • Film them, get them to blog/tweet/... during and write a report afterwards
  • Obvious variants (VP for a day, Board member for a daya, Jimbo for a day, ...)

Advantages (of ED for a day)

  • Get a community member right into the heart of the operation.
  • Unparalleled access, feedback.
  • A valuable potential recruitment stream, moving selected workers towards formal contracts or employment
  • Random alternative point of view

Disadvantages (of ED for a day)

  • Cost in terms of plane tickets; staff time
  • ED's work may be largely confidential eg staff, contracts
  • Reputational risk
  • Might have zero impact in the community beyond the one person

it is english, amerikan, an amerikan way of operation

  • but wiki is international
  • we (that means not everybody) don't share the today way of interpreting things
  • your thinking categories are western-world
  • you limit choice to that you can imagine att first hand
  • it's hard to explain: if your system, which is in your head, just allows an answer a or b - can this be too overruling because there are perhaps c and d and e you dont ask for or dont give space for because you dont imagine it. Be more open, should I suggest. Ta in people from asia och afrika. Ta in hole new viewingexperiences.

WMF on the ground



  • Local offices of WMF, integrated into the WMF
  • Touch points for interaction with local community on the ground

Advantages (of WMF on the ground)

  • Diversify workforce across locations, time zones, languages, communities
  • Greater understanding in WMF staff of local communities, cultures, ways of communication
  • Multiply possibilities for face-to-face interaction with community through formal and informal interactions: conferences, workshops, seminars, tutorials, hackathons, editathons, touchpoints, meetups, social events
  • Global pool of talent to draw on
  • Pay rates cheaper almost everywhere compared to SF

Disadvantages (of WMF on the ground)

  • The proposal assumes that offices are needed, focusing on a proposed solution rather than the stated problem. It may be easier to focus on how to increase remote work (and reduce hiring in San Francisco), something the WMF has already been doing.
  • Dispersed offices require greater management, time and expense; lead to legal, personnel and financial management issues.
  • Separate offices may develop their own groupthink divorced from WMF HQ and mainstream effort.
  • Cost of living and/or demand of developers from the labour market are in some areas even higher than in San Francisco.

Build up the community structure



  • Build up structures or formal organisations on geographical and subject-specific (SIG) lines
  • Local or interest groups may or may not be development working groups
  • Probably incorporating or repurposing existing chapters
  • Support financially and administratively out of WMF but with self-organised governance
  • Consider organising SIGs alongside or as part of existing open-source programmes

Advantages (of Build up the community structure)

  • Better cooperation within the community
  • Clear lines of communication between community and WMF
  • SIGs will probably be able to bring expertise to WMF that it cannot reasonably expect to develop internally
  • Groups can build outward-facing credibility in open source and open data communities

Disadvantages (of Build up the community structure)

  • Costly
  • Brand control issues
  • Reputational risk in the event of governance failure
  • Divergence may occur making movement seem or even be divided
  • Risk of power struggles being the locus of community/WMF interaction
  • Top-down or externally mandated structure may not have community buy-in
  • Formal membership requirements may clash with culture of pseudonymous contributions

Rebuild WMF as part of the open-source software movement



  • Dismantle the existing WMF programme and project mechanisms and rebuild around existing formal open-source communities and structure
  • WMF management confined to laying out strategic imperatives, road-mapping and personnel management and review
  • Open-source misses the point

Advantages (of Rebuild WMF as part of the open-source software movement)

  • Slimmer management structure
  • Projects are completely visible to the community through existing tried and trusted mechanisms
  • Further force multiplication from volunteer contributors already in opensource but not currently members of Wiki community
  • Constant constructive criticism from other volunteers
  • Demonstrates WMF commitment to open-source in a radical and public way, send out very positive messages to world at large
  • Demonstrates WMF commitment to collaborative working in a radical and public way, sends out very positive message to existing community
  • Staff not dedicated to open-source may wish to leave

Disadvantages (of Rebuild WMF as part of the open-source movement)

  • Radical change in an organisation may unsettle employees, hence making them less happy and less productive.
  • Radical change in a volunteer community may unsettle volunteer members, hence making them less happy and less productive.
This seems improbable, under the circumstances. The volunteer community is more likely to be happier and more productive knowing that something is being done about a situation they're now widely unhappy about. --Pi zero (talk) 20:16, 4 September 2014 (UTC)[reply]
  • Not sure whether any organisation has transformed itself like this, so no experience to draw on
  • It's unclear what this even means, as WMF is already part of the open-source movement. Assertions to the contrary seem to be based more on "I don't like what the WMF decides to work on" and "I don't like that the WMF decides what to deploy to their websites" than on the WMF not being part of the open-source movement.
The case for that being a disadvantage is rather weak. One person claims to not understand what it means; if many people didn't understand that would be of more interest.

Internships for community members



  • Select members of the community for internships based on experience across the projects and skills or expertise relevant to WMF activities
  • Fund expenses for interns to work in WMF HQ in SF or in any other WMF location (see WMF_on_the_ground)
  • Interns experience day-to-day work
  • Interns report back to community

Advantages (of Internships for community members)

  • Interns convey community point of view into WMF teams, experience WMF point of view and report back to community
  • Structures for onboarding/accepting interns are already in place (including some internships of community members in the past).

Disadvantages (of Internships for community members)

  • Cost, HR and legal issues for non-local workers
  • Reputational risks associated to unpaid intern concept
  • Intern work is probably not value-for-money, benefit comes from communication not from real work
  • Developer and legal internships already exist. Community internships in the past have tended to result in interns quitting their home communities.
  • Interns may be considered quislings for the WMF if they present ideas to their communities that are more closely aligned with the WMF position than that of vocal members of their community




  • A forum for users to propose requirements or suggestions for improvement that are not WMF priorities
  • A forum for volunteer developers to offer their time
  • A forum for WMF staff to offer advice, coordinate with existing WMF roadmap
  • A working space to progress agreed proposals to grant application and funding

Advantages (of Triangulum)

  • Developers can find projects that suit their interests and expertise
  • Users can make proposals and see them assessed on a scale for fit with WMF roadmap
  • WMF staff can coordinate paid with unpaid effort
  • Grant applications are more likely to be productive, aligned with assessment criteria and gain funding

Disadvantages (of Triangulum)


Community engagement for all



  • Formally place an appropriately demanding community engagement objective in everyone's job description
  • Develop a (short) list of roles and behaviours and assign them appropriately to the posts
  • Develop suitable metrics for engagement across the various roles
  • Metricate using standard measures such as 360 feedback

Advantages (of Community engagement for all)

  • Community engagement becomes part of the day job, not an optional extra
  • Staff are allocated time and resources to engage the community
  • Staff are motivated to engage and to do well at engagement
  • Staff unwilling to engage the community may choose to leave

Disadvantages (of Community engagement for all)

  • There may be posts for which the appropriate level would be zero
  • Behaviours and personality types may not always be suited to engagement
  • Staff unwilling to engage the community may choose to leave
  • Risk of encouraging box-ticking rather than genuine engagement culture
  • Difficult to measure success
  • Does not exactly propose how to rebuild the decision-making, development or communication process - vague idea

Define goals before you start




Every project must be the solution to a real and agreed upon problem and must be helpful for at least one stakeholder group, without handicapping other involved groups - Pareto optimization

Development suffers from a lack of and constantly shifting goals. MV with all the existing and discussed bells and whistles and bags and warts is getting almost as cluttered as the commons media page it was supposed to replace. No one really knows what Flow is supposed to do or not to do. Goals are necessary to guide the development process. They can be changed during the process, but only for good reasons.

Those goals should be communicated and discussed before the decision to implement can be made. If communities don't see the purpose of a project, it should be critically reassessed and probably its priority reduced.

The goals must be seen within the ecosystem of the solution. Media must not be displayed without license information. Editors need the ability to collaborate on drafts. Article content must allow copying to discussion space and vice versa.

From the goals the design of a project can be derived. Not the other way round. You don't start with the wish to create a flashy social media thingy before you understand about talk pages. You don't design image layouts without learning about the functions of the current layout.

Before you start you need to define benchmarks. Without them you will never know if you reached your goals. Once X man months have been invested, no one can look at results without prejudice anymore.

During development you need to understand about your principles. Agile does not mean throwing pre-alpha software at your user base. Test. Test again. Test under realistic conditions and with real data. Ugly data. Very ugly data. Do stress tests. Throw data at your code until the servers glow. See what happens. Don't rely on models and interfaces. Someone out there already has subverted your models or he will do so tomorrow.

Present your product only when you have something to show.

Don't expect praise. Working software is not a miracle to users, it's what they expect.

Advantages (of Define goals before you start)

  • Working software, working communities.
  • Most of this is already being planned for larger WMF projects.

Disadvantages (of Define goals before you start)

  • Responsibility. For communication, for product, for process, for the budget.
  • Does not focus on developing these goals together
  • May be too much bureaucratic effort for small projects
  • Volunteer devs cannot be forced to follow this plan, so it will never be implemented for every project.

Clearly refocus all future work around content work/editing


What/How? (Clearly refocus all future work around content work/editing)

  • It occurred to me, recently, that the undo button opens an edit box so that I can add in a relevant change that a newcomer tried to add, but didn't succeed.
  • I would like everything to open an edit box, or be close to do so.
  • All activity should be centered around an edit box.
  • When reviewing newly created pages, I would like the process to start with opening an edit box. The toolbar should have some extra buttons relevant to the current task -- but that is all. I should be able to tidy up the article grammar and formatting in the same edit which approves it.
  • How — this should be all semi-automated.

Advantages (Clearly refocus all future work around content work/editing)

  • Long-term sustainability of all work on-wiki.
  • Stronger contact with newcomers. Having their edits expanded and their articles expanded is one of the adorable things they like during their first on-wiki day.

Disadvantages (Clearly refocus all future work around content work/editing)

  • Does not actually make sense in all cases: readers may want to read, not edit, as much as we might like them to edit.
  • Raw wikitext may not be the best way to accomplish things, while VisualEditor may interfere with some workflows.

Get rid of biases and misconceptions about unregistered contributors


What/How? (Get rid of biases and misconceptions about unregistered contributors )

  • Introduce beta tab and preferences for unregistered contributors. (Obviously some of the preferences would be missing, such as personal e-mail.)
  • Start assuming that unregistered contributors are good content editors and people with knowledge, which they're eager to share.
  • Focus on resolving issues raised at Musings about unregistered contributors gradually.
  • Possibly introduce means (such as a cookie or a manually entered nickname) of identifying a single human on a shared IP. These are both easy to circumvent by a troll, who'd pretend a new person each time. This needs to be designed carefully in a way that adds convenience for good-faith contributors, so that they can choose whether or not to use mathjax preview or mediaviewer on individual basis.
  • I'd perhaps continue to treat IP folks as a single entity, but word the relevant places (contributions page, etc) appropriately, suggesting that it may reflect multiple people where they share an internet access point.

Advantages (of Get rid of biases and misconceptions about unregistered contributors )

  • Direct editor engagement by defaulting to feature-rich software by default where a person visits a Wikimedia project first time.

Disadvantages (of Get rid of biases and misconceptions about unregistered contributors )

  • A little time needed to design. But I would personally expect only a little rewording needed. (To add in proper warnings about possibility of some pages and interface to reflect on many people, if the internet access point is shared.)
  • May involve reinventing registered users in a way that pretends not to be registered users, and likely with lessened security.
  • People who refuse to register may refuse to use these features as well, for the same reasons.

Guided tours for new products and features



  • Brief videos or slideshows showing new or updated features shown to all users prior to a product launch

Advantages of Guided tours

  • Gives users a basic idea of what a new feature will look like and some general ideas of usability

Disadvantages of Guided tours


Develop for a global userbase not just for those with new kit



  • Don't just write for new machines, develop New Software to work on almost all of the kit that our editors and readers use.

Some WMF developments are written to support a wide range of machines, others such as the visual editor are written to take advantage of the functionality of new machines, even if that means running very slowly or not at all on older kit. This proposal is that in future the development strategy should be to support as much of the editor base as possible, and when programs will degrade performance on machines to default those machines, browsers or operating systems to software that does support them.

Advantages of coding for all our editors

  • Avoids requiring editors to upgrade their devices in order to use all the available bells and whistles.
  • Doesn't degrade the performance/experience of editors with old kit.

Disadvantages of coding for all our editors

  • Does not take advantage of more powerful machines some users have.
  • If taken to the extreme (design for old hardware, rather than for using new features when available while gracefully falling back on older platforms), leads to a dated site with poor support for modern platforms.

Never ever English Wikipedia first




English Wikipedia should never receive new code first, especially new features or new extensions. (See deployment for status quo.)

Advantages (of Never ever English Wikipedia first)

  • Can focus on getting features deployed first to multiple places where they are specifically asked for and the users are ready to collaborate.
  • Manageable amount of feedback and issues to deal with before the minimum viable product is ready.
  • Multiple smaller wikis can be managed at the same time, avoiding the risk of spending months developing code tailored to the needs of a single wiki which ends up not working anywhere else.
  • Forces the product manager to have an actual plan, in order to balance the contrasting needs received since the beginning from multiple wikis and to leave enough breathing space for "last wiki surprises" (after the code is enabled in the last places), rather than be driven by the ocean current.
  • Ensures that any documentation by the development team lives in and is translatable, to the benefit of all users.
  • Not using your largest database as a testbed is good practice in the software industry, which practically all users will understand and agree with (also thanks to direct experience with the nefarious consequences of not following it).

Disadvantages (of Never ever English Wikipedia first)

  • Less exciting deployments.
  • Some shortcuts would be forbidden: namely, English Wikipedia specific extensions which were made in the past (e.g. PageTriage) and deployment as a way to gauge English Wikipedia consensus by the size of the outcry rather than by dialogue.
  • In testing something, there will always be a first wiki. It might be considered unfair for one wiki never to have this burden.

Bug Prioritisation by editors




When there are known bugs the multiple reports of the same bugs can drown out reporting of new ones - when you hit the sort of problem that happened with V/E AFT and Media Wikiviewer you need a drop down menu so you can just click on the known bug you've hit. That way you can add to the importance of bugs - "x other people have agreed that this bug is a problem" rather than start yet another duplicate thread about the same bug.

Our current system of prioritisation of bugs by developers risks prioritising ones that are technically interesting to work on, and de prioriting ones that anyone with a bit of programming skill can work around. Hence the greater priority that say AFT or Media Viewer had over important bugs such as reducing edit conflicts.

Advantages (of Bug Prioritisation by editors)

  • More important bugs will get a higher priority.
  • It's an industry standard, very understandable by users. Bugzilla is the most common FLOSS issue tracker, as well as the one wikimedians are most familiar with, and provides votes. So do Q&A sites, UserVoice and other tools used by websites and software industry to manage user requests/reports.
  • We can import thousands of votes from our own Bugzilla database, serving as a starting point and reducing the person-hour cost of the operation.

Disadvantages (of Bug Prioritisation by editors)

  • Old bugs that have been accumulating votes for a decade or so may seem more important than a new bug that has only been getting votes for a few hours.

Measure edit conflicts




When two or more editors try to edit the same section of an article or a single section article at the same time one of them will experience an "edit conflict" and have a rather non-iterative process to recover their edit.

Because the edits don't stick we don't publicy log how many edit conflicts take place, though if there isn't a log somewhere it should be possible to create one.

Measuring edit conflicts would give us a way to predict how likely an edit conflict is to drive away a newbie, and the proportion of newbies that we lose due to edit conflicts.

Advantages Measure edit conflicts


At the moment we simply don't know whether this is a minor irritation that helps deter the spammers and the clueless from Wikipedia, or whether this ranks with deletionism as one of our biggest biters of newbies.

Sometime around 2007 we saw the rise of the template taggers who template new articles for hypothetical others to improve. Templating a brand new article that doesn't have a section is frequently going to cause an edit conflict to the person trying to make their second edit to the article they just started. Measuring edit conflicts should give us an idea of the proportion of new editors that we drive away in this manner.

Measuring the proportion of newbies we lose through edit conflicts will either confirm the view of some that fixing such edit conflicts should be one of our top IT priorities, or it will knock out one of the most plausible theories for Wikipedia going off the boil.

Disadvantages Measure edit conflicts

  • Actually fixing some of the bugzilla requests to reduce edit conflicts, some of which date back to 2006, would probably be less work and far more useful.

Out of Scope


In case any ideas are deemed out-of-scope, please move them here rather than removing them entirely.

New page or section listing references



  • Add a new page listing potential references next to "article" and "talk page" or as a new section on the top of talk page.
  • Sources clearly isn't reliable and relevant to the article should not be added, or others can remove it and warn the user who added it.
  • Encourage esp. new users to add sources as a start of editing Wikipedia.
  • Various users are able to give different comment to the source, about its content or reliability.
  • If a reference haven't been added to the article, it should be marked.

Advantages (of new page or section listing references)

  • Some users may find an important source but won't write it to the article (due to not familiar of writing in the language, not familiar with this topic that fearing damage the article or error interpretation of the source, or simply have a phobia to write an article). They are able contribute in this way.
  • Doing this will be easier than write new materials in the article for newcomers. So it will encourage more editors to make their first step, and may encourage more readers become editors.
  • Editors from another languages of Wikipedia are able to see links in this language and use translation machines to understand the content and use them on their own wiki.
  • Some users are interested in writing an article but couldn't search thoroughly on the internet to get the whole picture (due to bad search skills or the imperfect search engines). This feature will be help them too.
  • Sometimes users may have different opinions on whether a source are reliable or have a different interpretations. It will provide a place for them to discuss.
  • The current talk page is serving the above functions, but this feature will help references - very essential for a public-editing encyclopedia - organize better.

Disadvantages (of new page or section listing references)

  • Risk of advertisement links.

Make gadgets more useful


What (Useful Gadgets)

  • When writing a gadget, I often encounter routine tasks, such as a need to edit a template or one of its params (when handling an unblock request, a draft review, or similar), need to edit a page, communicate via ajax and leave an error message to the user.
  • But there is no framework allowing me to easily manipulate templates, and
  • editing pages has to be done by hand by making an ajax call and fiddling around with a PROMISE thingy in JavaScript, and then fiddling with DOM by hand to figure out where to display an error message.
  • Gadgets are often documented in only one language and used in only a few wikis.
  • This should all be improved. Look at Mozilla Jetpack. It provides easy access to most commonly used UX and functions-idioms.
  • See ongoing work at mw:User:Legoktm/Gadgets 2.0 Audit

Advantages of Useful Gadgets

  • Eases routine work across all projects
  • Allows building very specialistic workflows

Disadvantages of Useful Gadgets

  • Relies on JS which not all users have?

Lift the ban on article creation by unregistered contributors



  • At a point Jimmy Wales supported an experiment of barring unregistered contributors from creating articles at English Wikipedia.
  • This experiment was never reviewed.
  • New tools were introduced since then - flaggedrevs, page review tools.
  • Yet many unregistered contributors leave because of this barrier. We don't see them. We don't know how many.
  • This should be fixed.
    • Lifting the ban could be treated as an experiment rather than a fix.
  • There should be a lot more human helpers helping to maintain the wiki.

Advantages (of Lift the ban on article creation by unregistered contributors)

  • Not losing newcomers (editor engagement)

Disadvantages (of Lift the ban on article creation by unregistered contributors)

  • More work processing crap - the usual work on big wiki, just needs proper semi-automated software without templates on talk pages.
  • New page patrol is already at a critical backlog. We would need to draw more volunteers to clear the backlog first.

Stop hiring people from outside


What/How? (Stop hiring people from outside)

  • Pick up active technical contributors of Wikimedia projects (or people with strong technical backgrounds who are active in the Wikimedia community in non-technical capacities) and hire them.
  • Look specifically for people with history of past successful projects (ones that are well programmed, well designed, well documented, got deployed, are maintained well and have good user reception) within the Wikimedia movement.
  • These people would know the needs of the Wikimedia projects very well.
  • Provide JS/PHP training to them as necessary.

Advantages (of Stop hiring people from outside)

  • Your team will know what the projects need.
  • The people you've hired will likely have strong connections with the existing community. They'll not look alien to it.
  • The result - team will do more of things the movement actually needs.
  • Wiki community is international, counters CA-centric bias

Disadvantages (of Stop hiring people from outside)

  • Lower initial experience level.
  • More effort required for training.
  • You might miss out on external perspectives, experiences and new technological developments (living in a bubble / groupthink).
  • The narrower the recruitment base the less likely to find star quality performers.
  • Easier to teach a star developer the rudiments of wiki than to make a wikipedian a star developer.
  • Having, and keeping, developers ignorant of wiki ways would force the community to articulate their needs
  • It is difficult to define what exactly counts for "outside". How many edits in what time are necessary for someone to be no longer considered an "outsider"?

Wikimedia Foundation- getting to know Wikipedia-community

  • There are IMO 2 options;
  1. experience by yourself; start editing Wikipedia. Write articles, upload images, find spelling mistakes. Whatever you prefer. Most of the Wikimedia Foundation-staff I saw so far has very limited contribution to Wikipedia if at all. How can they know the issues?
  2. find someone to tell you: I thought that was the idea of Community ambassadors. But maybe I'm mistaken? at least the one on de you can hardly call active. he does not even has voting right (less then 50 edits in the article namespac in one year)
I was told, on our village pump that there would be a brainstorm session going on, right here. I don't see any storm here but still, I'm very much interested in where I would have to ask for syntax highlighting in the standard editing window. It would help me a lot if items that are not in the main text, like, most importantly, things between reference tags, would be displayed in a different colour. It can't be that much of a problem. All kinds of editors, like the old ones for Turbo-Pascal, and the contemporary Notepad++ have syntax highlighting. Am I the first to come up with the idea that this would be very, very helpfull while editing articles in the default editing window? Wikiklaas (talk) 02:35, 22 August 2014 (UTC)[reply]
Syntax highlighting in the standard editing window - wikEd does this, see your gadgets tab. I would hope mw:Extension:CodeEditor can be given a good kick to learn wiki markup syntax rules, but I'm not sure whether anyone is working on that. --Gryllida 03:21, 22 August 2014 (UTC)[reply]

This is an important item. The WMF doesn't seem to have much understanding of who we are, how we work, or what we need. I am thinking specifically of Flow here - it doesn't matter how beautiful your vision is if that vision is not informed by good understanding. It doesn't matter how technically good the product is if the average reader's sociological-use of that product ends up damaging Wikipedia and subverting the MWF's core mission. The WMF seems to think every reader is a potential editor, and imagines that every editor is a contributor. The WMF seems to think that "editors" and "member of the community" are the same thing. The community shares the WMF's core mission, it is the community that works to ensure the value of content. However not all people-who-edit have any interest in furthering the WMF's core mission. It does not seem like the WMF knows what drive-by-edits are, what Single Purpose Accounts are, what PoV warriors are. To the WMF they are all "editors". I fear that if the WMF succeeds with their current vision for Flow&editing without understanding those issues, that they will end up with a gorgeous technically excellent product, but one where sociological factors result in corrupted content. All of the content may collapse if the WMF succeeds in a beautiful vision of opening the floodgates of super-easy editing without concern for bringing those editors into the community. Alsee (talk) 22:26, 2 September 2014 (UTC)[reply]

Communities with a Governance structure

  • If a community has a President then clearly the most appropriate and effective way of interacting with that community is via that President. The President is who you talk to, and the President has authority to speak for that community.
  • If a community has a Board of Directors or a Council then clearly the most appropriate and effective way of interacting with that community is via that Board of Directors or a Council. The Board of Directors or a Council is who you talk to, and the Board of Directors or a Council has authority to speak for the community.
  • Many of our communities have an RfC Governance structure. The most appropriate and effective way of interacting with that community is via RfC. If you want the community to answer a question, if you want a community to take action or assist you in some way, you post an RfC on the appropriate message board. Ask a local admin for assistance. If it is a matter of particular significance and you want to ensure broader community engagement then simply ask the admin for a longer running time and extended community notification. The closing results of an RfC should be treated as the voice of the community, no different from the statements of actions of a President. For interactions that are poorly suited to the RfC process, the RfC process may be used to request the community supply a better means of interaction. For example an RfC may delegate authority to an individual or group for that purpose.

A community respects actions taken via its governance structure. A community will not recognize any validity to actions or efforts which defy that governance structure. You may preform a survey of opinions of random members of the American Cancer Society, however that community will not recognize any authority in actions taken based on those results. If your random sample of American Cancer Society members says most want to have a joint fundraiser on Saturday, and the President of the American Cancer Society says the joint fundraiser is on Sunday, then the community is going to show up on Sunday and the community expects you to show up on Sunday. Alsee (talk) 12:55, 30 August 2014 (UTC)[reply]

"A community respects actions taken via its governance structure." Citation needed? Dubious, discuss? This is mostly true in a couple of projects, and it is somewhat true in a number of them, but it is not really accurate. In fact, there are links above that show examples of heavily advertised RFCs at en.wp whose results were completely disrespected by fellow community members. You don't seem to have a lot of experience yet, so you may not have encountered it, but your assumption is wrong. Volunteers are not bound in September by decisions that some of them made in August. In fact, the idea that w:en:Wikipedia:Consensus can change is an official policy at most of these projects (and rightly so: consensus does change over time). WhatamIdoing (talk) 19:51, 4 September 2014 (UTC)[reply]
I have no doubt that some may consider my edit history modest for being several hundreds, off and on over the last 8 years. I am the sort of geek who enjoys studying supreme court rulings for fun. I enjoy studying Wikipedia policies and following ArbCom proceedings and whatnot, for fun. I rapidly moved into significant activities such as resolving the Images of Muhammad controversy, and participating in Core Community RfCs. I believe a close examination of my edit history will show an uncommonly good knowledge relative to naked edit count. However trying to personally discredit me isn't really relevant here. What I say should be judged based upon the merits.

  1. Do you disagree that there have been escalating tensions between the WMF and the community?
  2. Do you disagree that much of the reason for those tensions is that the community feels the WMF has shown little or no respect for the RfC process?
  3. Do you disagree that the relationship between the Community and the WMF would be greatly improved if the WMF were to better engage with the RfC process?
    • That includes increased respect for outcomes they dislike, where those outcomes do not present technical difficulties, where outcomes do not raise legal concerns, and where outcomes do not conflict with WMF's defined mission and values. Case in point: Default setting for Media Viewer.
    • I am well aware of Consensus can change, thanks. And this is part of my point. Instead of steamrolling over a consensus the WMF doesn't like, the WMF can productively engage the community trying to change that consensus.
  4. Do you disagree that many in the community would set aside their personal disagreement on an issue, and respect RfC consensus, if the WMF had an RfC consensus backing them on some issue?
Speaking for myself, I think Media Viewer should default off. However I will firmly support Consensus if it goes against my personal view. That's how we work together. That's how we collaborate. Alsee (talk) 08:10, 9 September 2014 (UTC)[reply]
Only the last question needs an answer, because the answer to the last one makes the answers to the others unimportant: The English Wikipedia has a long history of not respecting the results of their own RFCs, such as this one. That link will take you to the archive of a community-initiated, community-led, widely advertised, community-approved RFC on a bug-free configuration change with zero legal issues and zero possibility of conflicting with the WMF's educational mission. The WMF devs (eventually) implemented the change exactly as requested. The response to the WMF doing exactly what the unanimously supported RFC requested was that the community declared that the WMF was forcing undiscussed, unrequested, and unwanted changes down their throats and immediately held another RFC to overturn the results of the first one.
Anyone who has followed RFCs over the years can likely give you other examples. (Pending changes springs to mind.) The core editors at the English Wikipedia care far more about "consensus can change" than about "respecting" decisions that they disagree with. RFCs at en.wp are not binding. The culture is different at other projects, where decisions are frequently binding at least in the short-term, but this is the reality at en.wp. WhatamIdoing (talk) 00:21, 14 September 2014 (UTC)[reply]
I had to re-write your links to point to Wikipedia instead of mediawiki, but no big deal. Looking at your RfC links, the only problem is see is your description of them. The first RfC started with 2 support and 2 people saying it needed to be a configuration option, then we have But let's first focus on the general proposal. Styling (or opt-out) is always an option. — Edokter (talk). After that 6 more people still explicitly raise the configuration-option issue, and it is reasonable to believe that many of the unqualified supports were doing so under the idea that "opt-out is always an option". There is absolutely nothing contradictory about the second RfC coming to an overwhelming consensus that (1) it should stay in place and (2) there should be a configuration option for it. There never would have been a second RfC if the substantial concern for a configuration option had been picked up from the first RfC as opt-out, and there's nothing wrong with a second RfC asserting the importance of configuration. However, to address the general case, there is always a chance that a software deployment change or software change won't turn out as well as expected. A CEO or Board of Directors can decide to roll out the hot-new Windows Vista corporate wide, and there's always some risk that people only figure out it's a flop after you start deploying. That is a universal issue, not an RfC issue. Passing an RfC establishes solid legitimacy. There are a lot of people who will set aside their grumbles to go along with a legitimate-process established consensus, people who will be outraged and fight-back if something is illegitimately railroaded out with disregard for the RfC process. "Leadership" is when you inspire people to follow. The WMF has not been showing any leadership - to the contrary the WMF has been stampeding the community in the opposite direction. The community wants to collaborate with the WMF, and the best way to gain the support of the community is to engage the RfC process as legitimate. Alsee (talk) 17:26, 18 September 2014 (UTC)[reply]
If you can reliably reproduce a link to the Wikipedia namespace sending you to MediaWiki, then please report your browser and OS information. A link to Wikipedia:V ought to take you to the article about the letter 'V' on Wikipedia, not to MediaWiki.
The "opt-out" system was always in place. The existence of the original RFC (it was one) did not establish "solid legitimacy". When people were told about both the method for opting out and the existence of the RFC, their response was not to say that they would "set aside their grumbles to go along with a legitimate-process established consensus". I don't actually recall seeing a single person say anything like that, although there might have been a couple out of the hundred or so who commented across multiple pages. Instead, the response was that no matter what the RFC said, they didn't like the change, they didn't care what other people said in previous discussions, and they shouldn't have to go to the (slight) trouble of opting out.
I understand that the German Wikipedia has a different culture, but that's en.wp's fairly consistent response: Consensus can change, and previous discussions are unimportant (unless they agree with me ;-). WhatamIdoing (talk) 23:21, 22 September 2014 (UTC)[reply]
Alsee, thank you for your thoughts. You mention that the communities want to collaborate with the WMF, and I believe you. I also recognize that different communities and projects have different ways of coming to consensus, and that is something that needs a fair amount of navigation and patience given that individuals and sometimes groups change their minds, or different parties enter into conversations at different times which can change the tone of any consensus.
That being said, is there a way to work within these current frameworks to build software that, on a basic level, would work for all of these communities with collaboration and input? Perhaps so, perhaps not. My question is: suppose we can - what does it look like? --Rdicerb (WMF) (talk) 23:20, 23 September 2014 (UTC)[reply]
I'll start with a huge selling point of a community-oriented process. In any process, any outcome will leave some people unhappy. In a community-oriented process any anger or discontent will not be directed at the WMF. Discontent will be greatly reduced by the diffuse blame. Discontent will be greatly reduced by respect or resignation towards democratic outcomes.
I admit I know little of how other projects differ from EnWiki consensus methods, but I believe people would be eager to develop and adapt to any reasonable cross-community process. I envision a WMF section at EnWiki Village Pump, and at an equivalent location on other wikis. This would work best with good transwiki support: The WMF could post information or an RfC at WMF, and have it show up on all the Wikis. The local community could handle the chaos of local discussion. That local process could generate community-voice answers or statements or questions or requests. If there's good transwiki support, those responses could show up at WMF central. Where an issue affects all Wikis, I see these community responses coming together in a cross-wiki consensus building. As far as translation issues, I believe other language wikis would be willing to take responsibility of translation to-and-from English if it gave them real involvement. I see WMF having a strong voice and leadership role. In a collaborative community model that takes the form of making good proposals, perhaps selling why it's a good proposal, but also respecting the rest of the community if they want to modify or reject the plan. It puts the WMF in a position of community leader rather than community ruler.
I would like to cite a past case with a very different model, but similar intent. The Image Filter Referendum on a filter to block Controversial_Content images. The WMF took on 100% responsibility for the process. The WMF undertook all preparation, undertook a mass cross-wiki survey, took on translation responsibilities, and took on all the work of distilling the chaotic responses into coherent results. The key intent was that the WMF was genuinely doing it's best to let the community make a decision. Some people might look at the results and think it failed because it never boiled down to a single concrete answer on a single concrete proposal. But when I look at it I see a clear consensus outcome. I see clear consensus on what form the filter would take (opt-in, block all images when active, easy to show any individual images, easy to disable entirely). I see opponents being willing to accept that consensus filter. I see both opponents and proponents reaching implicit consensus that such a filter is stupid and pointless. Consensus reached: No filter is preferable to a really stupid filter.
I think the first model I described, engaging existing community structures and letting communities handle much of the process, is vastly more viable than the mass-survey model. The WMF-run-survey model was way too heavy on the WMF for general use, and it runs into conflicts-of-interest issues when the WMF clearly prefers a particular outcome.
I considered discussing the Media View Community Consultation as a counter example, failed process, but maybe it's best if I don't risk mixing a negative tone into a promising positive discussion. Alsee (talk) 04:24, 26 September 2014 (UTC)[reply]

See also