Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Programs and events

< Community Wishlist Survey 2016
Programs and events
7 proposals, 99 contributors, 112 support votes



Support Wikipedia Education Program courses on Programs & Events Dashboard

  • Problem: Most of the education programs wordwide are using the deprecated EducationProgram extension. The Wiki Ed Dashboard supports university courses in the US and Canada, but the global Programs & Events Dashboard has disabled manyi of the features that are specific to education program use cases because they are designed specifically around Wiki Ed's program and are not configurable or internationalized yet.
  • Who would benefit:
    • Wikipedia Education Program organizers, instructors, and students would get a better user experience, along with good (and easy to compile) statistics about their impact on Wikipedia
    • Wikimedia Foundation developers would benefit from not having to continue maintaining the EducationProgram extension, if the Programs & Events Dashboard can meet the needs of current EP extension users well enough for the extension to be disabled.
  • Proposed solution:
    • Add support for a WikipediaEducationProgram course type on the Programs & Events Dashboard, including timeline functionality
    • Enable on-wiki edits from the Programs & Events dashboard to mirror the course pages to Wikipedia
    • Work with users of the EducationProgram extension to determine any additional blockers to migrating off of the extension
  • Phabricator tickets:

Community discussion

@Ragesoss: Thank you for proposing this idea! I would definitely translate and pitching people in our community to come here and vote yes for this proposal. I think the mirror function is really an amazing feature that would benefit a lot when we reach out to K-12 and higher education field. Also I think there is already some fabricator tickets related to this proposal, such as this link? --Liang(WMTW) (talk) 03:28, 9 November 2016 (UTC)[reply]

Thanks, @Ragesoss:! Like Liang, I would also like to endorse this request. Highly important to anyone doing outreach, not only EDU-Wiki. Best, Shani Evenstein 12:31, 21 November 2016 (UTC)[reply]
It is great to see this proposal and I absolutely endorse it. As Eduction program leader, I know that it is vital, and I think it will improve management of many other kinds of outreach activities. --Sara Mörtsell (WMSE) (talk) 13:23, 21 November 2016 (UTC)[reply]
Fully agree, we need it --Ата (talk) 13:24, 21 November 2016 (UTC)[reply]
I endorse this proposal, the whole community will benefit with it. --Paolaricaurte (talk) 19:27, 21 November 2016 (UTC)[reply]

Voting – Support Wikipedia Education Program courses on Programs & Events Dashboard

  1.   Support :-) Sage (Wiki Ed) (talk) 19:13, 28 November 2016 (UTC)[reply]
  2.   Support Arian Talk 13:24, 29 November 2016 (UTC)[reply]
  3.   Support Richard Nevell (WMUK) (talk) 13:24, 29 November 2016 (UTC)[reply]
  4.   Support Carlojoseph14 (talk) 14:36, 30 November 2016 (UTC)[reply]
  5.   Support Sadads (talk) 14:53, 30 November 2016 (UTC)[reply]
  6.   Support Maybe can be in different language. Murbaut (talk) 13:54, 1 December 2016 (UTC)[reply]
  7.   Support --Satdeep Gill (talk) 17:57, 1 December 2016 (UTC)[reply]
  8.   Support Ermahgerd9 (talk) 18:44, 1 December 2016 (UTC)[reply]
  9.   Support Sandiooses (talk) 17:45, 2 December 2016 (UTC)[reply]
  10.   Support Pamputt (talk) 11:05, 4 December 2016 (UTC)[reply]
  11.   Support YjM (talk) 20:23, 4 December 2016 (UTC)[reply]
  12.   Support Martin Urbanec (talk) 20:34, 4 December 2016 (UTC)[reply]
  13.   Support Wesalius (talk) 05:09, 5 December 2016 (UTC)[reply]
  14.   Support Annakoppad (talk) 5 December 2016 (UTC)
  15.   Strong support -Liang(WMTW) (talk) 08:23, 6 December 2016 (UTC)[reply]
  16.   Support Muhraz (talk) 16:06, 6 December 2016 (UTC)[reply]
  17.   Support Blue Rasberry (talk) 19:33, 6 December 2016 (UTC)[reply]
  18.   Strong support — Rhododendrites talk \\ 22:17, 7 December 2016 (UTC)[reply]
  19.   Strong support John Carter (talk) 22:24, 7 December 2016 (UTC)[reply]
  20.   Support --OrsolyaVirág (talk) 11:50, 10 December 2016 (UTC)[reply]
  21.   Support many people involved in the Wikipedia Education programs, including me, call for improvement of the Dashboard and this would be an important step. --Vojtěch Dostál (talk) 13:08, 11 December 2016 (UTC)[reply]
  22.   Support - DPdH (talk) 13:24, 11 December 2016 (UTC)[reply]
  23.   Support--Alexmar983 (talk) 02:25, 12 December 2016 (UTC)[reply]
  24.   Support Michal Lester לסטר (talk) 11:49, 12 December 2016 (UTC)[reply]
  25.   Support Guettarda (talk) 16:37, 12 December 2016 (UTC)[reply]
  26.   Support, or otherwise support Education Programme extension. At the moment neither education tool has appropriate support — NickK (talk) 17:39, 12 December 2016 (UTC)[reply]

Tool to post barnstars after large scale meetups

  • Problem: It is hard to collect the usernames from large scale multi-location meetups like en:Art+Feminism. Specifically:
A way to post barnstars on each user's talk page afterwards. [research paper] indicates that interaction on user pages is a key indicator of user retention, so we hope to be able to start with barnstars, and then later check in. en:User:MediaWiki_message_delivery doesn't look like an actual message, nor is it from a recognizable user that they can write back to. Doing this manually is not an option for an event with thousands of participants.
  • Who would benefit: Anyone who is organizing large scale meetups.
  • Proposed solution:
  • More comments: There is a chance that there are other extant solutions to these problems. We have consulted with many other Wikipedians associated with WMNYC and A+F, and this is what we have been able to figure out.
  • Phabricator tickets:

Community discussion

Hi Theredproject: I've done some work on the Programs & Events Dashboard, and it'll be able to handle both #1 and #2 for you. The barnstar idea is new to me, and it's a good idea. That doesn't really fit the title of "Scripts and tools to support metrics" -- I think it needs to be the focus of its own proposal. Do you want to make the proposal just be about that? -- DannyH (WMF) (talk) 00:56, 24 November 2016 (UTC)[reply]

Hi User:DannyH (WMF), if the Dashboard will handle 1 & 2, I've edited above, leaving the strikethrough to show history, but making it mostly/only about barnstars. Theredproject (talk) 16:46, 24 November 2016 (UTC)[reply]

Theredproject: I edited the proposal so that it's just about the barnstars, and I put your original proposal on the archive page: Scripts and Tools to support Metrics for large scale meetups. Does this work for you? We can change it back if you want. -- DannyH (WMF) (talk) 21:04, 24 November 2016 (UTC)[reply]
The Programs & Events Dashboard could probably also do the barnstar delivery; the Wiki Ed dashboard currently does automatic welcome messages from the user who is supporting each course, and making a more flexible system that could be used for after-event messages delivered by the facilitator of each event would be fairly straightforward. The Programs & Events Dashboard isn't currently configured to make on-wiki edits, but it could be.--Sage (Wiki Ed) (talk) 19:09, 28 November 2016 (UTC)[reply]

Voting – Tool to post barnstars after large scale meetups

  1.   Support communication and engagement with large groups after the event, is supper important, Sadads (talk) 15:27, 28 November 2016 (UTC)[reply]
  2.   Support, I've been missing this for the editathon I organised last year SvenDK (talk) 21:51, 1 December 2016 (UTC)[reply]
  3.   Support Great idea, will help with user engagement. Oaktree b (talk) 16:33, 2 December 2016 (UTC)[reply]
  4.   Support --Yiyi (talk) 15:36, 3 December 2016 (UTC)[reply]
  5.   Neutral local american Wikipedia bling-bling. --Sargoth (talk) 10:19, 4 December 2016 (UTC)[reply]
  6.   Support--Alexmar983 (talk) 10:51, 4 December 2016 (UTC)[reply]
  7.   Support As someone who just manually left several dozen barnstars on user pages for WikiConference North America, this could have made my life easier. Events we know how to do, post-event engagement is harder, and any tool that helps reach out to users after an event will boost recruitment and retention, which is good for the community as a whole. Gamaliel (talk) 03:54, 6 December 2016 (UTC)[reply]
  8.   Support But it sounds like this is coming by way of the Programs & Events Dashboard. Blue Rasberry (talk) 19:30, 6 December 2016 (UTC)[reply]
  9.   Oppose as redundant, Special:MassMessage can do this job by posting barnstars the same way as it posts any other messages — NickK (talk) 17:40, 12 December 2016 (UTC)[reply]

Allow any language to be the source for translations in Meta

  • Problem: Some Wikimedians organize events that include editing in several languages and for diferent projects. Last year, for instance, an event was held in my town to edit Wikipedia, Wikidata, Wikivoyage, Wikiquote and Wiktionary in Catalan and Spanish. A home page in es:wiki, ca:wiki, etc wouldn't be appropiate. It can be done in Meta and then translated. But in order to be translated, texts in meta have to be in English. It's prety absurd to translate a text from Catalan to English and then back to Catalan, when what we really want is a language-neutral space.
  • Who would benefit: Organizers of multilingual multiproject events.
  • Proposed solution: Allow any language to be the source for translations in Meta.
  • More comments: We have had activities with up to eight languages (and English was not one of them).

Community discussion

I've also been thinking about this after trying to run several multilingual competitions and projects who's interface always ends up being a bit of a bodge job, I outlined an interface here however I think that the list of articles could also be generated in other ways e.g Wikipedia categories or custom lists, perhaps using page piles. The interface is based on Dynamic Listeria

Thanks

--John Cummings (talk) 20:36, 17 November 2016 (UTC)[reply]

Voting – Allow any language to be the source for translations in Meta

  1.   Support Lsanabria (talk) 19:50, 28 November 2016 (UTC)[reply]
  2.   Support JAn Dudík (talk) 22:07, 28 November 2016 (UTC)[reply]
  3.   Support Guycn2 · ☎ 19:10, 29 November 2016 (UTC)[reply]
  4.   Support Ainali (talk) 15:46, 30 November 2016 (UTC)[reply]
  5.   Support Trizek from FR 19:47, 30 November 2016 (UTC)[reply]
  6.   Support 4nn1l2 (talk) 12:41, 1 December 2016 (UTC)[reply]
  7.   Support Good Murbaut (talk) 13:55, 1 December 2016 (UTC)[reply]
  8.   Support --Goombiis (talk) 18:26, 1 December 2016 (UTC)[reply]
  9.   Support Juandev (talk) 21:12, 1 December 2016 (UTC)[reply]
  10.   Support --Gestumblindi (talk) 21:56, 1 December 2016 (UTC)[reply]
  11.   Support NMaia (talk) 01:01, 2 December 2016 (UTC)[reply]
  12.   Support Jmvkrecords ⚜ (Intra talk) 10:06, 2 December 2016 (UTC).[reply]
  13.   Support Laurentius (talk) 19:27, 2 December 2016 (UTC)[reply]
  14.   Support --Framawiki (talk) 20:48, 2 December 2016 (UTC)[reply]
  15.   Support --Yiyi (talk) 15:37, 3 December 2016 (UTC)[reply]
  16.   Support--Alexmar983 (talk) 10:52, 4 December 2016 (UTC)[reply]
  17.   Support Pamputt (talk) 11:03, 4 December 2016 (UTC)[reply]
  18.   Support --Yeza (talk) 09:59, 5 December 2016 (UTC)[reply]
  19.   Support Being truly multilingual is core to our mission. MartinPoulter (talk) 13:44, 6 December 2016 (UTC)[reply]
  20.   Support Muhraz (talk) 16:05, 6 December 2016 (UTC)[reply]
  21.   Support Noé (talk) 17:19, 9 December 2016 (UTC)[reply]
  22.   Support --Nikola (talk) 11:28, 10 December 2016 (UTC)[reply]
  23.   Support Yes, we need that !!! --Lyokoï (talk) 23:25, 10 December 2016 (UTC)[reply]
  24.   Support --Plagiat (talk) 18:46, 11 December 2016 (UTC)[reply]
  25.   Support--David1010 (talk) 20:36, 11 December 2016 (UTC)[reply]
  26.   Support --Kenzia (talk) 11:43, 12 December 2016 (UTC)[reply]
  27.   Support, yes please, it is very difficult to translate pages regarding local projects (such as chapter or user group activities) into English first. However, if source language is not English translator may be able to switch to translation from English (e.g. source language is Spanish, English translation is available, so I want to translate it into Ukrainian using English as source language) — NickK (talk) 17:42, 12 December 2016 (UTC)[reply]
  28.   Support--Mikheil Talk 21:22, 12 December 2016 (UTC)[reply]

Article tracking tool for Wikiprojects, edit-a-thons and other campaigns, based on Wikidata

  • Problem: I have participated in many editing campaigns, wikiprojects and edit-a-thons so far. I notice that it's always difficult to keep track of which articles to write (always a mess of many lists, some more well-managed than others), which articles have been written, which need to be written from scratch, which can be translated from other languages, etc. We also try to keep track of how many articles are created or improved over a given period of time, and this is also difficult to track. Wikidata + a dedicated tool could help greatly, see description below.
  • Who would benefit: Organizers of editing campaigns, wikiprojects, edit-a-thons...
  • Proposed solution: Create a tool that functions in the following way:
    1. Items for wanted articles are created and collected on Wikidata as a 'set'. It must be possible (and easy) to add new items to that set when the campaign runs!
    2. The tool takes the set of Wikidata items and then generates a to do list on the relevant wiki, with the following minimal features:
      1. A to do list of articles to write (redlinks) and to improve (blue links). Options to organize the list (headings, sorting...) would be handy, because many projects will work with hundreds of topics.
      2. If the article exists in other languages - the interwiki links are stored in Wikidata - links to these articles are shown in the to do list as well, next to the redlink/blue link. Preferably there would be a direct link to the ContentTranslation tool.
    3. Less essential, but great to have: statistics about progress of the project/campaign, e.g. a table per week that shows how many articles were created/improved, completeness graphs, etc. Very motivating!
    4. As noted above, it must always be possible to add new items to the base set, for instance when a participant has decided to write an article on a relevant topic that was not initially listed yet.

Wittylama used a custom set of scripts for the Europeana Art History Challenge that is related to what I'm describing here. Would be great to have something generic that can be applied especially on Wikipedias.

  • Phabricator tickets: none yet

Community discussion

@Spinster:, thanks for adding this to the list. I would like to endorse this request. It is indeed needed and I believe it could be another feature of the new Programs & Events Dashboard we are working on (see Sage's wish at the top of the page). Best, Shani Evenstein 12:37, 21 November 2016 (UTC)[reply]

Spinster, I think a lot of the functionality that you want already exists in the Programs and Events Dashboard. Have you seen it? -- DannyH (WMF) (talk) 01:16, 24 November 2016 (UTC)[reply]

I didn't know it yet, but I just checked it out and tested it with a pseudo-mini-real case (the participants of Dutch-language Wikipedia's gender gap task force and its gargantuan worklist of articles).
I notice the tool is very much targeted towards education projects, which is of course great, but it's a different case than what I'm describing, which is a 'horizontal' (sometimes large) group of existing and new editors working together outside of that context, trying to structure its workload.
Functionality that I want, but that is not present in the P&E dashboard at all:
  1. Start with Wikidata items and produce the worklists from there. This is at the core of what I think is needed. I want to be able to collect topics and then let the tool figure out if we have a case of brand new articles that are needed, or translations of existing articles in other languages are an option.
  2. I want the worklists to appear on wiki, not in a separate dashboard - imagine something similar to Magnus' ListeriaBot which generates lists from Wikidata every day. Of course the dashboard could be the place where the Wikidata items are collected, triggering a daily bot run that then would update the Wikimedia page(s) that are indicated as designated places for the lists to be visible to the community.
  3. Ability to structure the list of articles by theme, for instance - you need to imagine cases of projects that have to do lists that contain hundreds of articles. Using metadata from Wikidata would help here too!
Functionality in the current P&E dashboard that is present but is not helpful for my case:
  1. Tracking users' contributions - not essential to what I want. I want worklists based on Wikidata in the first place (see above).
  2. The 'articles edited' list is meaningless. Many if not most Wikipedia writing projects and campaigns will work with a mix of new and experienced editors. I have added a few experienced editors to the test set I have created, and now see all their contributions, which gives an overflow of unrelated edits AND feels like a needless privacy violation for me; I feel uncomfortable with that (although I do know their edit histories are public, I don't want them presented to me so prominently). I can imagine it is a useful feature for new users though, but even then those users are free to work on other topics and it would be meaningless and slightly intrusive, IMO, to see those contributions appear in the dashboard.
  3. The concept of "assigning" articles doesn't make sense. People are free to choose what they do.
  4. Article ratings are not applicable to Dutch Wikipedia.
  5. As the creator of the program, I cannot be a participant. I want to be a participant! I am also working on the articles!
  6. Apparently only one person can administer a program? I would want to open this up to a group of people.
Summarizing: no, the P&E dashboard does not do what I want and emphasises a lot of stuff I don't need. I see very clearly that the P&E dashboard comes from the education background but volunteer-driven campaigns are quite different. I have a hunch that just updating the current tool might not produce what I describe above, but maybe others have different ideas. Spinster (talk) 12:01, 24 November 2016 (UTC)[reply]
Thanks @Alexmar983: also to fulfill the requirements of an italian user, I developed Monalbot. In my opinion the tool fulfills the requirements of "which articles have been written" and also "keep track of how many articles are created or improved over a given period of time" by a group of students or users. More info can be found [1]. Of course I'm willing to cooperate to improve the tool. Note: it does not use Wikidata. --FabC (talk) 11:38, 4 December 2016 (UTC)[reply]

Spinster, I wonder if the new Commons Datasets table support can be used as the data store for this? This way the data can be stored there, and formatted/processed in any wiki you may need it at? --Yurik (talk) 05:28, 25 December 2016 (UTC)[reply]

Voting – Article tracking tool

  1.   Support We need better tracking of content-area bound sets of data, alongside time bound (P&E Dashboard), and user submitted (Wikipedia Asian Month tool). Sadads (talk) 15:30, 28 November 2016 (UTC)[reply]
  2.   Support as proposer. Spinster (talk) 15:27, 29 November 2016 (UTC)[reply]
  3.   Support, today I'm crafting such lists by hand. A very time consuming job. SvenDK (talk) 21:55, 1 December 2016 (UTC)[reply]
  4.   Support NMaia (talk) 01:01, 2 December 2016 (UTC)[reply]
  5.   Support Jane023 (talk) 12:40, 2 December 2016 (UTC)[reply]
  6.   Support Europeana Art History Challenge was a nice proof of concept. Next step would be nice. Multichill (talk) 12:42, 2 December 2016 (UTC)[reply]
  7.   Support, building the tracking for the EAHC was very tricky and itself was based on the existing work of the Wikimedia CEE Spring 2016 project - so that's at least two use-cases showing proof-of-need. Wittylama (talk) 13:42, 2 December 2016 (UTC)[reply]
  8.   Support Sandiooses (talk) 17:41, 2 December 2016 (UTC)[reply]
  9.   Support--Alexmar983 (talk) 10:52, 4 December 2016 (UTC)[reply]
  10.   Support Pamputt (talk) 11:04, 4 December 2016 (UTC)[reply]
  11.   Support --Papuass (talk) 21:17, 5 December 2016 (UTC)[reply]
  12.   Support It would also be useful if Wikimetrics has a report showing which articles a group of users edited (though that is probably a separate issue). Richard Nevell (WMUK) (talk) 10:40, 6 December 2016 (UTC)[reply]
  13.   Support Muhraz (talk) 16:06, 6 December 2016 (UTC)[reply]
  14.   Support --Nikola (talk) 11:29, 10 December 2016 (UTC)[reply]
  15.   Support - DPdH (talk) 13:13, 11 December 2016 (UTC)[reply]
  16.   Support I can even think of individual-user uses for this.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:10, 11 December 2016 (UTC)[reply]
  17.   Support--David1010 (talk) 20:37, 11 December 2016 (UTC)[reply]
  18.   Support Quiddity (talk) 09:20, 12 December 2016 (UTC)[reply]
  19.   Support --Kenzia (talk) 11:41, 12 December 2016 (UTC)[reply]
  20.   Support Michal Lester לסטר (talk) 11:50, 12 December 2016 (UTC)[reply]

Enable on-wiki lift for account creation limit at a specific IP range

  • Problem: When participating of outreach events with editing and account creation, like workshops or editathon, organizers and new contributors usually face the problem of limiting the account creation number to 6 per each IP in a day. That is kept for a good reason and prevents abuse on most cases. However, we always see that problem on events and we have ways of evading that that are not known to most users and are often unsuccesfull due to comunication issues. Whether because a sysadmin can't be found in time or because the IP can't be discovered previously enough to give time to allow the lifting, the current system has many flaws. Thus, we frustrate new users and force regular users to create accounts for others, which is below optimal.
  • Who would benefit: **On these events, new users will be able to create their own accounts and starting the process of learning how to manage the wiki interface.
    • Organizers will have less work (and more time for other things) on creating accounts.
  • Proposed solution: I hope this is something feasible and I am not suggesting something impossible terribly difficult to be done. My suggestion is providing a way to add a parameter on a IP or an IP range for temporary lifting the account creation limit on them. This could be handled, for instance, by Stewards who are usually available on IRC or by other means to attend the request.
  • More comments:
    • It is suggested that the wiki interface (whether on Meta or local wiki) should be prefered instead of any other way.
    • Sysadmins are welcome to suggest rules and limits for enabling the lift for the ranges.
  • Phabricator tickets:

Community discussion

My experience is that even when all efforts are done to explain people to bring their accounts ready from home, a number of people won't do their homework. I know, it would be better if they did but... this proposal makes sense to me. B25es (talk) 19:26, 19 November 2016 (UTC)[reply]

Support. This is something we regularly deal with when organizing Art+Feminism events. We have taken the approach of requesting temporary account creator permissions for at least one organizer at each event. This has generally worked, though we have experienced static when making those requests. Theredproject (talk) 18:34, 20 November 2016 (UTC)[reply]

this is a major headache at editathons - but we are going to try account creation at meta and let the SUL do the rest. hack english. Slowking4 (talk) 15:08, 21 November 2016 (UTC)[reply]

I am afraid I have to agree with ^demon here. This problem is described in a way that's already leaning too much to a solution that I'm not sure I'm happy about. I think you have to take a step back here: You want to have a user-friendly system where you can have an event where multiple people create new accounts, possibly from the same ipaddress, without running into problems. Multichill (talk) 13:51, 2 December 2016 (UTC)[reply]

What are the problems exactly? I don't understand what demon said either...—Teles «Talk to me ˱C L @ S˲» 02:18, 4 December 2016 (UTC)[reply]

Voting – Enable on-wiki lift for account creation limit

  1.   Support Sadads (talk) 15:28, 28 November 2016 (UTC)[reply]
  2. Strongly   Oppose Not because it's a bad idea or I don't think stewards/meta admins should be able to do this, but because any implementation now would likely be an end-run around proper on-wiki configuration management (granted, this has always been a slow-moving project). Avoiding the hard work means we'll end up with yet another "stuff the config into NS_MEDIAWIKI and call it a day" solution which will make me so very very sad. So yeah, I'll oppose any project to introduce more on-wiki config that doesn't Do It Right. ^demon (talk) 19:34, 28 November 2016 (UTC)[reply]
  3.   Support Doc James (talk · contribs · email) 04:01, 3 December 2016 (UTC)[reply]
  4.   Support The workaround through other wikis is annoying --Sargoth (talk) 10:21, 4 December 2016 (UTC)[reply]
  5.   Support --β16 - (talk) 11:26, 5 December 2016 (UTC)[reply]
  6.   Support This is time consuming and frustrating for event facilitators and attendees. Wikipedia already has a steep learning curve, we don't need a choke point for the very events designed to assist people with that learning curve. Gamaliel (talk) 04:25, 6 December 2016 (UTC)[reply]
  7.   Support I am not sure I understand the solution but as an event organizer I know the problem very well. Blue Rasberry (talk) 19:31, 6 December 2016 (UTC)[reply]
  8.   Support -- Amanda (aka DQ) 21:18, 6 December 2016 (UTC)[reply]
  9.   Support --Frank Schulenburg (talk) 04:43, 8 December 2016 (UTC)[reply]
  10.   Support I have witnessed this issue derail an editathon. Tdslk (talk) 20:02, 11 December 2016 (UTC)[reply]
  11.   Neutral With support for dedicating resources to the underlying problem that ^demon describes. Quiddity (talk) 09:21, 12 December 2016 (UTC)[reply]
  12.   Support Michal Lester לסטר (talk) 11:48, 12 December 2016 (UTC)[reply]
  13.   Support Guettarda (talk) 16:35, 12 December 2016 (UTC)[reply]
  14.   Support, not sure this is the best solution but some exceptions per IP should exist — NickK (talk) 17:44, 12 December 2016 (UTC)[reply]

Integrate being able to use open license text in the Visual Editor toolbar

  • Problem:
  1. Wikipedia has pages for around 5% of the topics that could be covered and many of the existing pages are not of a high quality.
  2. Wikipedia is written by a diminishing number of volunteers.
  3. Outreach events to train new editors (including expert outreach) has a less than 5% (and possibly much lower) retention rate.
  4. Wikipedia is still has a high learning curve despite VE addressing some of the technical barriers to contribution.

However there are a huge number of open license sources of text which could be used to create some of the missing articles which are written by experts:

  • Over 9000 open license journals.
  • Galleries, libraries, archives and museums (GLAM) who produce text under an open license.
  • Government text that is available under an open license.
  • Intergovernmental organisations e.g UN agencies (UNESCO has over 1200 open license publications).

Currently there has been little work done to make openly licensed text easy to integrated into Wikimedia project pages with clear attribution. I have worked on a simple guide and VE compatible template but is not widely used.

  •  
    Toolbar button
  •  
    Box to add open license text

Whilst much of the media content displayed on Wikipedia comes from 3rd parties, estimated at 50% with over 3 million images from Flickr alone there is very little text on Wikipedia originally from other sources. Some of the early growth of Wikipedia came from importing an out of copyright Encyclopedia Britannica however this approach hasn't been used very much since. By adding a text import tool into the VE toolbar it will help to mainstream and make it easier to reuse text from other openly licensed sources, allowing editors to do more more work in the time they have to volunteer for Wikimedia. I have done some work with editors to import descriptions of UNESCO Biosphere Reserves into Wikipedia to create new articles and improve existing ones and it takes around 15 minutes to create a new article including references, links and images.

  • Who would benefit:
  • Readers: Increased number of subjects that include text written by experts and an expanded number of articles overall.
  • Editors: The ability to create new articles and improve existing articles much more quickly using open license text rather than creating text from scratch.
  • Open license publishers and authors: get a vastly increased audience for their work through Wikipedia that could be easily measured.
  • Non open license publishers and authors: Provided with an additional motivation to adopt open licensing
  • Phabricator tickets:

Community discussion

@John Cummings: If clear instructions or a clear mechanism for adding openly licensed text is needed, could you explain which specific situations this refers to? Trying to understand the root problem behind this proposal (in order to discuss the best potential solutions), why is adding openly licensed text with its corresponding reference to an article (just like adding any other quoted text) not sufficient? Or is this about entire articles based on openly licensed text? Or something else? --AKlapper (WMF) (talk) 12:28, 9 November 2016 (UTC)[reply]

Please also add a link, to an example of what kind of edit the tool would simplify. I think this article creation is what you want to simplify. If that is not a perfect example, please point to (or create) something better? If I understand correctly, there are a few core aspects that you are proposing streamlining, including: Adding a well-formed edit-summary. What else? Thanks! Quiddity (WMF) (talk) 20:44, 9 November 2016 (UTC) Ping @John Cummings: Just in case you didn't get the earlier ping for the questions above. :-) Quiddity (WMF) (talk) 21:55, 13 November 2016 (UTC)[reply]

Thanks Quiddity (WMF) and AKlapper (WMF), I've expanded my proposal, please let me know if you have any questions, there is a lot more information and community discussion on the Ideaslab proposal I wrote that I've linked to (first link in proposed solution section). --John Cummings (talk) 14:39, 17 November 2016 (UTC)[reply]

Ryan Kaldari (WMF) So the attribution template is working and looks acceptable, but could be better, here is an example. The current system for importing open license text is here, I worked hard on making it much more user friendly but its still a bit of a bodge job. The crux of this is I want a tool on the VE toolbar to generate this template and help the user fill in the fields. The main problem is that there are 100,000s of openly licensed articles in journals and other sources written by experts that may suitable for inclusion in Wikipedia but aren't being added because not many people are aware this is possible or how to do it. A tool in VE that allowed people to easily and quickly import and properly attribute openly licensed into Wikipedia.

The overall mechanism would be:

  1. Editor finds only license text source they want to use on Wikipedia
  2. Editor uses VE to paste the text into Wikipedia and properly attribute the source
  3. VE has form as pictured above that allows user to copy in text and get proper attribution on the same way as the reference tool URL looker upper works.
  4. Editor makes links to other articles and adds in citations for the sources the text cites
  5. Article now has text from external source that is properly attributed

I'm sorry if I'm not being very clear with this. I think one of the issues is that this proposal process is framed around problems and solutions and I'm suggesting something that is an improvement of a process and tools that already exists.

Thanks

--John Cummings (talk) 11:02, 23 November 2016 (UTC)[reply]

Voting – Integrate being able to use open license text

  1.   Support NMaia (talk) 01:04, 2 December 2016 (UTC)[reply]
  2.   Support Gamaliel (talk) 03:59, 6 December 2016 (UTC)[reply]
  3.   Support Richard Nevell (WMUK) (talk) 10:41, 6 December 2016 (UTC)[reply]
  4.   Support Lawsonstu (talk) 11:18, 6 December 2016 (UTC)[reply]
  5.   Support Sara Thomas Lirazelf (talk) 13:24, 6 December 2016 (UTC)[reply]
  6.   Support There is huge potential to expand Wikipedia with suitable freely-licensed text, and a small amount of work to ease this process should give disproportionate benefits. MartinPoulter (talk) 13:47, 6 December 2016 (UTC)[reply]
  7.   Support Someday Wikimedia projects must be more accepting of open text. Blue Rasberry (talk) 19:32, 6 December 2016 (UTC)[reply]
  8.   Support Getting this implemented would be a great step forward in terms of tapping into the growing reservoir of openly licensed texts available elsewhere, including from open-access scholarly sources and possibly by way of Wikisource. -- Daniel Mietchen (talk) 07:02, 10 December 2016 (UTC)[reply]
  9.   Support - Understand the problem, not so much the solution. DPdH (talk) 13:16, 11 December 2016 (UTC)[reply]

Make finding and sharing documentation much easier

  • Problem: Documentation on Wikimedia is sometimes very hard to find because it spread over many different Wikimedia sites and beyond, including being produced by other open organisations like Creative Commos
  • Who would benefit: Anyone looking for documentation
  • Proposed solution: Create an improved version of the Wikimedia Documentation Directory. The Wikimedia Documentation Directory is a tool for finding and indexing documentation that is easy to use and contribute to. People are be able to add resources in any language and it will include non-Wikimedia resources hosted on external websites.
Improvements and additions are outlined on an IdeaLab page including:
  • Automatically scrape Wikipedia:NAMEOFRESOURCE and equalent from other Wikimedia sites.
  • Import tools from Hay’s Tool directory
  • Curated links from other sites
  • Directory of Open organisations with shared goals
  • Maintain user friendly form but do not require someone to manage the updates through Google sheets
Additional features:
  • A recently added section
  • Multiple languages
  • Multiple sources if more than one organisation is involved
  • Should run off a public database other people can edit and a public directory of open groups
  • Some sort of rules about granularity may be helpful?
  • Category structure for tags
  • Phabricator tickets:

Community discussion

Hi John, it sounds like you want to see user friendly (both to search, contribute to and read) improvements to existing projects, such as the Wikimedia Resource Center and the Wikimedia Documentation Directory. It sounds like the ideal directory would also pull in resources from outside of Wikimedia projects. I know you have been interested in this kind of tool for a few years - indeed it is challenging to learn about new tools, the status of projects, find tools to solve specific problems and find out about other organizations with resources that are of interest to our community. It would be great to have a super directory of open source resources, but the scope of the project may be too large for any one team to support. I've posted a few questions below about how we might break down this project into components that are more achievable in the short term.

  • What are the most important changes you would like to see to the Wikimedia Documentation Directory? How would those changes effect users?
  • What are the biggest problems with the Documentation Directory?
  • How would curation occur? Would people upvote the most useful resources, leave reviews or would they be curated by a person?
  • What kinds of questions or problems would a user be able solve using this directory?

You do not have to answer these questions specifically - my only intention is to help refine the idea into specific actions and outcomes to get it ready for the voting phase.--KHarold (WMF) (talk) 02:30, 23 November 2016 (UTC)[reply]

Hi KHarold (WMF), to answer your questions:
  • What are the most important changes you would like to see to the Wikimedia Documentation Directory? How would those changes effect users?
    • To have much more content in it, I think this is caused by the answers to your second question.
  • What are the biggest problems with the Documentation Directory?
    • Reliant on one person to add things from the Google form into the tool
    • Does not automatically index Wikimedia help pages
    • No one is adding content
  • How would curation occur? Would people upvote the most useful resources, leave reviews or would they be curated by a person?
    • Having upvoting etc would be amazing, also being able to tag resources, the most important things would to be able to find things easily and to add things easily, I think all features would emerge from those goals.
  • What kinds of questions or problems would a user be able solve using this directory?
    • Finding documentation relevant to what they are doing, there is a huge amount of repetition and bodge jobs because people are unaware of previous work in an area so cannot copy and improve on what they have done.
Thanks
--John Cummings (talk) 15:37, 26 November 2016 (UTC)[reply]

Voting – Make finding and sharing documentation much easier

  1.   Support Libcub (talk) 02:49, 2 December 2016 (UTC)[reply]
  2.   Support Richard Nevell (WMUK) (talk) 10:41, 6 December 2016 (UTC)[reply]
  3.   Support --R. S. Shaw (talk) 17:03, 9 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Programs_and_events&oldid=27874216"