This page creation is motivated by problems and misconceptions of the processes underlying software of the Wikimedia websites. A better collaboration on software is necessary, and this page is intended to outline major problems and proposed solutions.

In a nutshell: The wiki software lets sysops turn off some features in a broken way using JavaScript, but they lack config access. This is an authorization issue. It may be adequately resolved by trusting our sysops with requesting configuration changes.

To do so, proper software and policies for requesting feedback from the userbase as a whole are required;

  1. site notice is a means of reaching it, for example; but
  2. the tools for receiving structured feedback are missing (remember all the manual work you had to do about the privacy policy and then terms of use change feedback; to my knowledge, this idea is not documented or discussed anywhere on this wiki), and
  3. RfCs might be often written poorly (such as 'would you like to go backwards?' or 'what do you think of this change? [with no other questions posed]') which renders them useless even after solving the above. (To my knowledge, discussed here.)

Wikimedia Engineering is a Team dedicated to improving software across the Wikimedia projects. They consist of numerous staff and contractors who are members of the specific teams. These teams work together to improve the software.

In a nutshell
  • The monthly reports highlight latest work of the Wikimedia Engineering.
  • Your expectations of what an improvement would be like may differ from what the Engineering team thinks they are. It in fact is always different. That these people aren't psychic is a fact.
  • If you'd like to see or change a new feature, you can
    • tell the Wikimedia Engineering about it (the beta features tab of your preferences is an easy place to do so for some features which are undergoing testing), or
    • program it and request that your code is deployed. MediaWiki is free software; you have the freedom to study, modify, and re-distribute its code. (You are welcome to run a copy of any Wikimedia project if so you like, because their configuration and content are also free.) It would undergo extensive code review and deployment of some features may require community consensus; outreach and reaching this consensus is your task.
Community discussion

Please be catalytic. Community discussion of the website software is encouraged.

  1. Write down what you think. Meta is, for instance, place where many contributors gather to draft new technical ideas and essays about Wikimedia projects. You're welcome to draft a new software idea — tag it with {{essay}}, make it translateable — and gather community feedback.
  2. Ask the right audience for feedback. [This is hard, we need better tools here to reach the right people (readers, editors, reviewers...). Not just a village pump as only a small group reads it, but even that is better than nothing!]
  3. Take notes. Aggressively process the feedback you receive.
  4. An idea usually evolves. Fellow contributors may reject some of your thoughts or add new ones.
  5. Re-visit step 1: Correct your idea based on feedback; re-iterate until you get it deployed (more on this below), or until you have already got support from the entire userbase (by means of site notice on relevant wikis).
Getting your things deployed
  • Proper discussion and drafting may be enough to get your thing done. Forward it to the correct Team and ask it for feedback.
  • If Wikimedia Engineering can't do what you'd like by request, do outreach for technical contributors. Look for people who'd like to program the necessary tools and make the necessary changes.
  • You can get extra funding (to do it yourself or hire someone). The individual grants program is here to support your work on something other than MediaWiki itself, or otherwise the Google Summer of Code funds MediaWiki and extensions work (find a student on your local wiki who would like to program the feature, and a mentor who'd like to mentor your task.) A local Chapter may also fund any work if finds relevant through the PEG grants program (chapter or some extra people from the WMF Grantmaking team would review your proposal).
Missing infrastructure

The steps above stress a need in some extra tools or things. Feel free to add bullet points for new thoughts or add nested bullet points (**) to sign your support or share thoughts about an existing idea.

RFC Guidelines

edit
  • RfC guidelines — thoughts on how to best put an idea to get efficient input from others. Motivated by the please stop asking people whether they'd like to go backwards thought, I've started a section which can now be found at this talk page.

Tools and policy on getting users´ feedback on software

edit
  • Policy for requesting feedback on software. This should start with a relevant village pump and end with a site notice, but something inbetween is needed and is missing.
  • Tools for requesting feedback on software. These are lacking. Wikimedia Engineering uses SurveyMonkey, for instance, which is a closed product. More discussion of that here, but a separate article or section about this should be created to think through possible solutions.

Proper documentation of recent Engineering work for end users (& tools for its visibility)

edit

Better means of getting your thing deployed

edit

A lot of people feel community involvement in development is lacking. How would you like to improve it?

Wiki markup?

edit
  • Move all tools to wiki markup, so that development is easy, like editing articles or templates? [1]

Community involvement in decision making?

edit
  • Adding a mechanism for community participation in decision making before it is too late?

Central place for templates and gadgets?

edit
  • Global js is already available; someone please add more details and thoughts what needs to be done here next

Your subject

edit

Your content; optionally signed if you like