Community Tech/Project ideas

Below are some ideas for projects for the new WMF Community Tech team. This team will focus on meeting the needs of active Wikimedia editors. While the new team is still getting itself organized and staffed, if you have ideas for what this team might work on, feel free to add to the list.

See also the existing lists on our issue trackers:

• MediaWiki and Wikimedia open reports, by number of votes
• Long-standing "epic" bugs
• Issues by topic: phab:tag/wikisource/, phab:tag/commons/, phab:tag/wiktionary/, SWMT, ...

Add Citoid support to RefToolbar

RefToolbar is a default gadget on the English Wikipedia. It adds a "cite" button to the WikiText editing toolbar for quick and easy addition of commonly used citation templates. It is probably the most common way that citations are added into Wikipedia. It also has an auto-fill feature that lets you create a full citation by just entering the ISBN, DOI, or PMID number. There is a new Citoid service that is being developed for the VisualEditor that will allow the same auto-fill capability based on raw URLs. Since Citoid is an API service, there is no reason it can't be added to the WikiText editor as well through RefToolbar.

Adding Citoid support to the wikitext editor is already planned. Whatamidoing (WMF) (talk) 00:18, 12 May 2015 (UTC)

@Whatamidoing (WMF): Do you know what team is going to be working on that? Collaboration? Kaldari (talk) 17:23, 12 May 2015 (UTC)

I believe it's the VisualEditor team, per mw:Editing#VisualEditor team and phab:T94223. Quiddity (WMF) (talk) 17:33, 12 May 2015 (UTC)

Looks like the bug is currently unclaimed, but is being considered as a possible GSOC project for August. Specifically, the bug is about adding Citoid + TemplateData support to WikiEditor (unclear if this would include a citation template editing interface), which sounds like a larger project. My idea above is a quick hack just to add a Citoid lookup to the existing URL field in RefToolbar. RefToolbar already does API look-ups and has mappings for all the en.wiki citation templates, so this would be a smaller, short-term project. Kaldari (talk) 18:44, 12 May 2015 (UTC)

Pre-re-organization, it was definitely the Editing team, whose main project was VisualEditor, but whose scope also included the wikitext editor and Cite.php.

If you just want a quick hack, then User:Salix alba had one a while ago (I don't know its status). Whatamidoing (WMF) (talk) 17:58, 14 May 2015 (UTC)

Turn RefToolbar into a MediaWiki extension (or add it into the WikiEditor extension)

Right now Reftoolbar is only available on English Wikipedia (although there is a very limited version on Malayalam Wikipedia). It has frequently been requested that it be turned into an extension so that other Wikipedias can also use it.

WikiProject Wizard

Creating good WikiProject portals is extremely tedious and time consuming. It requires deep knowledge of WikiText template syntax and how to interface with the numerous tools and bots that exist for WikiProject portal use. Using FormWizard (or a new custom script), a wizard interface could be created for building WikiProject portals which would dramatically simplify the process.

As part of WikiProject X I wrote a requirements document for a Project Builder. I hope to work on it sometime in the next couple of months. harej (talk) 19:16, 11 May 2015 (UTC)

Turn HotArticlesBot into a publicly available service

HotArticlesBot is a ToolLabs bot that creates lists of articles that have been frequently edited within the past few days (typically as a subscription service for WikiProjects). The lists are based on the articles belonging to a particular category or including a particular template. It would be nice if there was a public interface that anyone could use to configure the lists that HotArticlesBot generates (via OAuth). It would also be nice if it supported projects besides English Wikipedia.

wikiproject.json is a publicly editable configuration file that will be used by my scripts for per-project configurations. HotArticlesBot and other bots are welcome to use it to store configuration data. harej (talk) 19:17, 11 May 2015 (UTC)

Color-coded WikiText editing

There have been some experiments around color-coded WikiText editing (including an English Wikipedia gadget and a working implementation in the Android app). This could be made into a real feature of the WikiEditor extension.

Is it like mw:Extension:CodeMirror? --Pastakhov (talk) 17:40, 20 May 2015 (UTC)

Yes I low the color coding of text that WikEd gives and miss it when I edit other languages. Sometimes I even work on text from other languages on En Wikipedia because we have better tools. We need a set of tools that the WMF will install on all Wikis that wish to opt in. Doc James (talk · contribs · email) 10:31, 21 May 2015 (UTC)

Expand on Magnus's ToolLabs tools

Magnus Manske has created dozens of useful community tools on Tool Labs. Many of these could be expanded, updated, or improved in various ways. Most of the code for his tools is publicly available on bitbucket.

Reasonator as stub page handler

On a small wiki, visiting any missing page or searching for a page not on the wiki should load up Reasonator in the local wiki language. For example, the Johann Sebastian Bach info page can and should be shown on all 272 wikis that don't have a J.S. Bach page. Global south!

Build better PHP API framework for MediaWiki

There are probably at least a dozen PHP API frameworks for MediaWiki. Most of them are old and with limited features. It would be nice to have one feature-rich well-maintained PHP framework that people could use for a wide variety of projects, similar to pywikibot for Python.

Build JavaScript API framework for MediaWiki

There is a small Node.js framework for MediaWiki as well as a fair bit of JavaScript API code within the MobileFrontend extension. These could be used as the basis for building a robust JavaScript API framework for MediaWiki.

Cool, but needs more details. Is this for use by external clients (the first link), external web pages, or on wiki pages (the Mobilefrontend link)? If the last one, how does it relate to the mediawiki.api module? -- SPage (WMF) (talk) 21:29, 15 May 2015 (UTC)

Improve copyvio detection bot

Take code at https://github.com/valhallasw/plagiabot and improve it:

• Better organization of the output (currently confusing and can be extremely long)
• Add interface for notifying editor that performed the copyvio (similar to PageTriage extension)
• Allow any WikiProject to subscribe

Talk to James Heilman User:Doc James / User:Eran about further ideas.

Article assessor gadget/extension

Create an easy to use interface for adding WikiProject assessment templates to articles. Would probably require some sort of JSON config page for listing the available templates. Would work similar to the WikiLove extension (which adds barnstars to talk pages). Kaldari (talk) 17:30, 19 May 2015 (UTC)

Timeline graphs of changes in article number and quality for WikiProjects

It would be nice to give WikiProjects a historical overview of the number and quality of their articles. This would require keeping a record of this data in a dedicated database on Tool Labs. Should investigate coordinating with WP 1.0 bot.

Multiple watchlists

Notes and bug-links collated at mw:Watchlist wishlist.

Add pronunciation buttons to Wiktionary

Either complete the development of the PronunciationRecording extension or create a new extension that automatically pronounces words based on IPA code.

WikiProject auto-invites

The impending WikiProject directory on the English Wikipedia will generate lists of active contributors to both the project space (the WikiProject page, talk page, subpages) and the project scope (articles and talk pages tagged by the WikiProject). This presents an opportunity for a bot to use this information for invitations. harej (talk) 19:19, 11 May 2015 (UTC)

Copyvio tools for Commons

Copyright on Commons is a topic that is at times, subject to abuse. Some images are left for long periods of time because people are afraid to tag them, and other times images are subject to the copyright whims of admins. It would be helpful if there were tools to both help detect possible violations (there are perhaps databases we can match things up against?) and a better method for screening images once detected.

Tools to support conference program development

There are now registration tools, but there are not necessarily tools to support conference development.

• The Wikimania programme committee utilizes a matrix to assess the committee's opinion on entries, however that matrix might be more challenging for some to manage. Might be helpful to either adapt these things to better use VE, or develop gadgets to help.
• Session evaluation tool - a method of collecting evaluations on sessions.

I suspect there are other tools that could be helpful for consistent conference tasks.

Report tools

Recent reports by things like OTRS have gone outside the traditional wikicode based report mold. Is that something that other entities should be encouraged to do? If so, should there be tools to help them do that to lower the technical skills needed and timeload on more tech savvy volunteers involved in those groups? Especially if the methods they are using are similar each time.

RFC tools

Perhaps there is a better way to capture ideas from the community for things like this document and RFCs. They tend to be very "Meta-Wiki" community focused outcomes, and become a bit complicated at times for less tech-savvy people (which sometimes may defeat the purpose). Perhaps there are tools that can increase language and cross-wiki participation. There might also be lessons from the IdeaLab project that could be applied.

This is really an area, where I agree we could truly use 'community' tech. Delection discussion/Voting/RFC'ing is a core element of our community workflows, that is sorely unsupported by tools. —TheDJ (talk • contribs) 18:17, 19 May 2015 (UTC)

Echo / Notifications for banner type information

Setup an interface to send notifications via Echo to users for things typically sent via banners. Also allow user to signup for things like Signpost notifications.

Cross projects notifications

Notify me when my name is mentioned or I receive a comment on meta in another project (Tell me on mediawiki that I was mentioned in meta).

Tools to check banners for accessibility issues

To help address concerns about colors and readability.

ContactPage interface

To remove the burden of updating text and basic setup from operations. Allows for wider usage for groups like AffCom.

Hiding UI elements

A very common request is to hide some element of the UI, but everyone has their own little pet peeves. The problem summarizes basically as: "We have 10000 UI elements and you can probably for each of those elements find one or more users who would like to hide it. 10000 UI options don't scale". My idea would be to make a gadget that alla 'Adblock' would allow you to highlight an area. The area would show the CSS selector for that part of the page. It then asks you to confirm if you want to hide this part only for this page or for all pages. We would save the result to global.css. Then everyone can adapt their user experience to their hearts content on their own responsibility. Some libs that could help with this: https://vimeo.com/52055686 and https://selectorgadget-plus.appspot.com —TheDJ (talk • contribs) 18:14, 19 May 2015 (UTC)

Work queues

We need work queues. A system, that shows articles that are in a certain group, for a certain reason and that need to be '(pre)processed' in a certain way. The person who can crack the task of solving this in a generic enough and expandable enough way, usable for multiple wiki types, in a way that editors can build new queues themselves, will be my ULTIMATE hero. Inspiration: WikiGrok + NewPagePatrol + WikiHow dashboards, Wikipedia:Huggle and Wikipedia:STiki, etc. I consider this the key to our long term survival. —TheDJ (talk • contribs) 18:29, 19 May 2015 (UTC)

And I saw this comment after I posted mine below about "Inventory pages". Agreed. Biosthmors (talk) 19:57, 19 May 2015 (UTC)

"Inventory pages" or nice "to-do" displays for each Wikiproject

Using the extensive collection of en:WP:TC (cleanup templates) we have in articles, I would like to see each Wikiproject have a dedicated page to show what tasks (and how many) can be done to articles within a WikiProject scope. (I would also like to see such a page for the entirety of each language Wikipedia.) I describe a version of this idea at Grants:IEG/Automated inventory pages for all WikiProjects. My inspiration for this idea is from http://www.wikihow.com/Special:CommunityDashboard Thank you. Biosthmors (talk) 19:56, 19 May 2015 (UTC)

central talk page notification, similar to xecho

This is very useful for stewards and other global users. Matanya (talk) 22:40, 19 May 2015 (UTC)

suggested multimedia for article

A tool similar to FIST, but a one that works well, and integrated. Matanya (talk) 22:45, 19 May 2015 (UTC)

+1. Relatedly, I wrote a tool to suggest images based on other wikis; much less ambitious than FIST, but it seems stable: GLAMify. Ijon (talk) 17:11, 21 May 2015 (UTC)

global, shared gadget list users can pick from

Yes, I know if you put your gadgets on meta it gets to all wikis, but this is not user friendly and has a lot of RTL issues all over the place. Matanya (talk) 22:46, 19 May 2015 (UTC)

And they need to be live searchable, so there is no reason to restrict on publishing gadgets, because "the preferences section already has 60 of them". —TheDJ (talk • contribs) 06:55, 20 May 2015 (UTC)

Editor Stats API/GUI

Create an API and/or GUI that can display information like:

• How many page views have the non-redirect articles User X has created received in their lifetime?
• How many bytes of text has User X added to all Wikipedia articles?
• User X has actively edited Wikipedia on how many days since they created their account? And what is their activity level in the past 6 months...

I think these, and other similar queries could be used to create a Contributor's Dashboard (along with other statistics) which would demonstrate a lot of aggregate information about who does what and how much of it. The goal would be to create snapshots of what people work on that would make it easier to know whom to contact and whom you're dealing with when you interact. It'd also serve as a potential 'gamifying' motivator by letting editors see the growth in their stats over time. Ocaasi (talk) 17:48, 21 May 2015 (UTC)

Start a project -- a real project with measurable goals and a schedule -- to reduce page weight

Background: Page Weight Matters, by Chris Zacharias

"Three years ago, while I was a web developer at YouTube, one of the senior engineers began a rant about the page weight of the video watch page being far too large. The page had ballooned to as high as 1.2MB and dozens of requests. This engineer openly vented that “if they can write an entire Quake clone in under 100KB, we have no excuse for this!” Given that I agreed with him and I was excited to find a new project, I decided to champion the cause of getting the YouTube watch page to weigh in under 100KB. On the shuttle home from San Bruno that night, I coded up a prototype. I decided to limit the functionality to just a basic masthead, the video player, five related videos, a sharing button, a flagging tool, and ten comments loaded in via AJAX. I code-named the project “Feather”.

"Even with such a limited set of features, the page was weighing in at 250KB. I dug into the code and realized that our optimization tools (i.e. Closure compilation) were unable to exclude code that was never actually used in the page itself (which would be an unfair expectation of any tool under the circumstances). The only way to reduce the code further was to optimize by hand the CSS, Javascript, and image sprites myself. After three painstaking days, I had arrived at a much leaner solution. It still was not under 100KB though. Having just finished writing the HTML5 video player, I decided to plug it in instead of the far heavier Flash player. Bam! 98KB and only 14 requests. I threaded the code with some basic monitoring and launched an opt-in to a fraction of our traffic.

"After a week of data collection, the numbers came back… and they were baffling. The average aggregate page latency under Feather had actually INCREASED. I had decreased the total page weight and number of requests to a tenth of what they were previously and somehow the numbers were showing that it was taking LONGER for videos to load on Feather. This could not be possible. Digging through the numbers more and after browser testing repeatedly, nothing made sense. I was just about to give up on the project, with my world view completely shattered, when my colleague discovered the answer: geography.

"When we plotted the data geographically and compared it to our total numbers broken out by region, there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia. Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load! This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to.

"Through Feather, I learned a valuable lesson about the state of the Internet throughout the rest of the world. Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. By keeping your client side code small and lightweight, you can literally open your product up to new markets."

Source: [ http://blog.chriszacharias.com/page-weight-matters ]

(Emphasis added, capitalization in original.)

(Reproduced under fair use: "The first factor is regarding whether the use in question helps fulfill the intention of copyright law to stimulate creativity for the enrichment of the general public, or whether it aims to only 'supersede the objects' of the original for reasons of personal profit.")

Given the above, I think that we should start a project -- a real project with measurable goals and a schedule -- to reduce page weight. --Guy Macon (talk) 22:21, 21 May 2015 (UTC)