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.
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".
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 MediaWiki.org 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.
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.
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.
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.
Prioritization process in a nutshell: Communication and collaboration about how the WMF prioritizes feature development.
The WMF announced an engineering re-org on 21 April, 2015, and new product teams based on audiences have been formed. These teams will be building out their product prioritization processes, and each team will have community liaisons embedded within them. Prioritization processes may vary slightly based on the team, but chances are high they will be based on data, feedback, and urgency. Specific information about tasks and products can be found in Phabricator. More information to come. -Rdicerb (WMF) (talk) 23:21, 22 April 2015 (UTC)[reply]
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.
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).
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 in a nutshell: Establish the Technology Committee to interface between users of all kinds and WMF and make decisions about technical matters such as product rollouts
The proposal indicates a request for involvement across more aspects of community, but introduces heavy bureaucracy into the product development process. With the growing UX Research team, more focus on data evidence, and increased ways of engaging communities at every stage of the product development process, the potential for involving more users and gathering more feedback encourages feedback from a broad range across different mediums (feedback pages, surveys, public bug triage meetings). That being said, this suggestion definitely comes from a good-faith intention (thank you! :) -Rdicerb (WMF) (talk) 23:35, 22 April 2015 (UTC)[reply]
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 in a nutshell: At which points in the product lifecycle should the community be involved and how? How do we measure community engagement?
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.
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.
(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.
Carefully staged rollouts in a nutshell: Defining a roll-out process that goes from 1% to 100% in stages across wikis horizontally with clear goals for converting from opt-in to opt-out. Incremental rollouts can gauge usefulness and usability of product features without affecting entire wikis
Yes, this is a desired and planned process, at least for very large new features, but the complexity of implementing staged-rollouts with all the nuances that we desire, the massive quantity of users, means that this will take more time to build both initial versions and more complete/complex versions. Internal discussion is ongoing. Quiddity (WMF) (talk) 23:59, 22 April 2015 (UTC)
To jump in - this is desired, but not necessarily technologically possible in all products at this time. @Greg (WMF): may have a better explanation for the Discussion page, or I can check in with him and follow up. -Rdicerb (WMF) (talk) 00:44, 23 April 2015 (UTC)[reply]
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
Notifications in a nutshell: Provide (opt-out) notifications when a new Beta Feature is available, or when a Beta Feature is calendared for production rollout, at least a reasonable time before that point (e.g. 4 weeks).
More deliberate notifications in a nutshell: Create/enhance communication and notification systems touching all Wikimedia projects to inform users of product or feature changes
The first idea is a desired feature (tracked at phab:T77347), and there are some good ideas here that I've copied to that ticket. The second idea (touched on mostly in the 2nd nutshell) will ideally be covered by features of the underway GSoC project, which aims to improve our Newsletter system(s); See details about that at phab:T76199 and mw:Extension:Newsletter/Proposal. Quiddity (WMF) (talk) 20:39, 4 August 2015 (UTC)[reply]
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
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
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
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
Yes it does, plz review patch?? (Patch no longer relevant, but this is work in progress by the wikiHow folks anyway)
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"
Workgroups in a nutshell: For complex projects requiring input, have a well-advertised mechanism by which communities can nominate workgroup members to work in close partnership (2+ hours/week) with the dev team, before, after and during the rollout.
We do reach out to different groups of users in various forms in different parts of the lifecycle (UX Testing, Papercuts, bug triage meetings, regular feedback) - and we'd like to discuss more options. However, this has the same problems as the #Technology Committee, but multiplied by the number of communities who might want to nominate representatives. Quiddity (WMF) (talk) 01:09, 28 October 2015 (UTC)[reply]
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.
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)
Microsurveys in a nutshell: More frequently and consistently integrate quick feedback tools for readers and editors into all products, and define clear approval threshold before features advance through the pipeline.
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.
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.
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.
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 in a nutshell: How do we involve active communities in User Testing? How do we inform about test results? How can users contribute to creating and supporting user tests?
The UX Research Team is slowly growing, and would appreciate anyone and everyone signing up to be a participant in user-testing (from core contributors to casual readers). See the second section of the Qualtrics signup page, in particular, for all the different Types of Research that we can opt-in to (fast surveys, in-depth surveys, 30 or 60 minute video/screenshare sessions with one of them or unattended screenrecording and self-narrated testing at usertesting.org, or even in-person design/usability research). The greater the quantity and diversity of participants, the better. Please spread the word! Quiddity (WMF) (talk) 23:40, 22 April 2015 (UTC)[reply]
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 in a nutshell: Given the challenges with language and locale -- a formalized information distribution and community support program that is implemented jointly with the community maybe the best approach to local, high-touch communication.
This is a request for a few things, including a single central communication hub, and a network of volunteer ambassadors. The latter is partially covered by https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors and that list could use more promotion and utilization (both by WMF and the communities); however, that needs to be balanced with the needs of the smaller communities, or busier volunteers, who prefer a low-volume & high-signal platform.
The idea of a centralized communication forum, for all the wikis, is partially what m:Wikimedia Forum is meant to be (along with m:Tech which is currently underutilized). This runs into the same problem of scale and filtering (some people will unwatch the page, if it becomes too active; Only the volunteers with the most free-time will read everything (and respond to anything)). The other problem is well-described at m:Not my wiki. However, there is ongoing work towards a centralized Hub that will hopefully help, or at least increase our collective understanding of the issues. Quiddity (WMF) (talk) 01:09, 28 October 2015 (UTC)[reply]
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.
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
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.
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 ?
Easy feedback in a nutshell: Let's source the software development ideas from the bottom to top, not the other way round.
There are some conflicting ideas: Essays are not an "easy" form of feedback. That being said, making the feedback loop easier is possible, just not in this fashion.
Per-extension centralized-feedback is already a component of a few extensions, such as VisualEditor, MediaViewer, Mobile Web, Mobile Apps. Additionally, any product in Beta Features has links to centralized and feature-specific information and discussion pages. This model should be encouraged, wherever appropriate.
Beyond the scope of an individual feature/extension, a generalized "feedback from every page" feature was tried in various iterations of the Article feedback tool as noted below (albeit with a focus on article-content), but the increased scale of triage that was needed (and even just acknowledgement of feedback) was too high for most communities, particularly given the low signal:noise ratio. The smaller communities which are perhaps most able to benefit from centralizing all software-feedback and bug-reports, already tend to place a link to their local "Village pump" equivalent into their mediawiki:sidebar.
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.
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 in a nutshell: People currently can edit articles, templates, and Lua code. Also userscripts and partly gadgets. I would like to make more of it a hobby.
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.
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).
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.
Structured feedback in a nutshell: Like survey-monkey but on-wiki and people should be able to discuss ideas of eachother
Yes, but not currently able to do onwiki - however, see the #Microsurveys answers above. There are also the complications of vote-counting (versus nuanced context). This might be possible through Flow eventually, but not for awhile. Quiddity (WMF) (talk) 01:09, 28 October 2015 (UTC)[reply]
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...
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.
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.
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.
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.
Title again in a nutshell: Stop using internal means of bug tracking and communication about decision-making. Also stop using any means of communication that may be released to public but is hard to process or follow-up.
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 mediawiki.org 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 mediawiki.org. 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.
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]
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).
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.
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 in a nutshell: The projects already cannot function without support from volunteer developer effort. Embrace that, and use it effectively, don't pretend it's an optional extra
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 in a nutshell: The community is spread out all over the globe. WMF should establish multiple presences locally as dispersed as possible.
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
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.
Rebuild WMF as part of the open-source movement in a nutshell: Dismantle existing project management and integrate formally into existing free/open-source communities
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.
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
Triangulum in a nutshell: Provide a one-stop forum for users to propose requirements, volunteers to propose effort, WMF to coordinate with roadmap and develop grant applications
Community engagement for all in a nutshell: WMF is part of a community of readers, writers, editors and developers, and that's part of the day job for everyone
Define goals before you start in a nutshell: Before implementation starts, the product team must define goals for the intended product and benchmarks to determine if the goal have been reached.
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.
Clearly refocus all future work around content work/editing in a nutshell: File viewing and patrolling activities should be all centered around edit activities.
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.
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)
Get rid of biases and misconceptions about unregistered contributors in a nutshell: During the development process, the Wikimedia folks occasionally assume that unregistered contributors are mostly readers, not editors, or people who should not have an opt-out button.
What/How? (Get rid of biases and misconceptions about unregistered contributors )
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 )
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.
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.
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.
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 mediawiki.org 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)
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.
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.
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.
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.
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.
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.
New page or section listing potential references in a nutshell: Establish a new page or as the first section of talk page encouraging users to list and comment on existed and potential 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)
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.
Lift the ban on article creation by unregistered contributors in a nutshell: At a point Jimmy Wales supported an experiment of barring unregistered contributors from creating articles at English Wikipedia. This drives people off and we don't know how many.
Stop hiring people from outside in a nutshell: People who worked on Facebook, Twitter, etc frontends have invaluable experience with PHP and Javascript etc, but they barely know needs of the Wikimedia movement.
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.
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
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?
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. --Gryllida03: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]
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.
Do you disagree that there have been escalating tensions between the WMF and the community?
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?
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.
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]
