Suggestions and proposals

Suggestions and proposals for Wikimedia, affecting all Foundation projects or just some of them; or addressing goals and tasks the Foundation should consider in the future. See also: initiatives.

Projects edit

New projects edit

What new projects should we be starting? What are the pros and cons of doing so? How can we protect small projects from abuse and founder effects in a scalable fashion? How can new projects be engaged in foundation-wide discussions and decision-making?

Features for existing projects edit

How can we improve on bugzilla's voting and urgency/priority mechanisms to support reviewing and prioritizing all manner of features, social, technical, visual, political and other?

Community scope edit

  • Wiki-time. The fast moving nature of the projects brings in some people, makes it addictive (which may not be a healthy thing), and drives rapid prototyping. It also drives some people away, and keeps them from being involved.
    so people making policy and high-speed changes often have addictive ties to the projects. and people with certain lifestyles or obligations have no venues in which they could develop ideas in a slower way, organizing discussions over time.

Feedback edit

  • Add 'feedback' and 'report a bug' links from every page on every project. This should be a one-click submission, something that records your SUL account and doesn't ask for another login. Feedback gets a suitable otrs queue; bugs are made a generic bug (people shouldn't have to choose which project they apply to before submitting; that's confusing). -- sj | translate | vote! |+ 18:50, 1 August 2009 (UTC)[reply]
  • Example bug I just encountered - make the amount of time 'Related changes' and 'newpages' info is stored guided by a # of days that one can set when creating a wiki... small wikis could use much longer defaults.
  • Add similar feedback links to mediawiki itself -- going to a different set of queues. -- sj | translate | vote! |+

Outreach edit

Publicity edit

Quality edit

Quality is a perennial bogeyman. Some leave the projects in frustration that quality will ever satisfy them. Others say that freedom and transparency are more important in the short run than quality - and always will be - and lead to the best quality in the long run. Elaborate plans are devised to trade off freedom for quality, to attract new specialized contributors, and to help produce polished final works from the fluctuating work on the Projects with minimal effort.

Strategy:Proposal:Develop systems for accuracy review is intended to support quality without impinging on freedom and is geared towards the maintenance of existing articles as well as the creation of new ones.

Governance edit

Some of the larger projects are struggling with scaling consensus to thousands of participants. The Foundation itself has a hard time attracting a balanced pool of candidates for key elections.

We need someone artistic to invent a glyph/logo for "disable transliteration" edit

Some of the Wikipedia pages that don't use the Latin alphabet use JavaScript to transliterate the keyboard characters. Examples are these sandboxes [1] [2]. This transliteration needs to be disabled when users add a link to the article in another language, or when entering non-native scripts for other reasons. There is a checkbox to disable this, but it is not obvious to people who don't know the language. This [discussion on the Wikipedia reference desk] shows that it has caused some editors wasted time.

We really want someone to come up with a glyph/symbol meaning "no keyboard mapping". Maybe Maybe something like "a➔ა" in a [No symbol] would do, or mabe a little keyboard with arrows to misc symbols in no symbol. -- Q Chris 08:00, 21 September 2011 (UTC)[reply]