The user right to edit summaries. For example, I've made an edit in some Lua-module but forgot to leave an explanation of the change for other developers. --[[User:AS|AS]] ([[User talk:AS|talk]]) 11:42, 18 September 2015 (UTC)
The user right to edit summaries. For example, I've made an edit in some Lua-module but forgot to leave an explanation of the change for other developers. --[[User:AS|AS]] ([[User talk:AS|talk]]) 11:42, 18 September 2015 (UTC)
=== New audio player with waveform display ===
{{Tracked|T103527}}
Basically something like [https://www.freesound.org/people/Coppersmith%20Barbet/sounds/33372/ this]. I think the improvement in usability compared to [[:File:Alde_Feanen_14.ogg|what we have now]] is quite obvious, at least for ''File:'' pages at Commons. Might be useful as an option in Wikipedia articles as well. --[[User:El Grafo|El Grafo]] ([[User talk:El Grafo|talk]]) 11:29, 21 September 2015 (UTC)
Revision as of 11:29, 21 September 2015
Below are some ideas for projects for the new WMF Community Techteam (more info about this team at their mediawiki.org and Phabricator pages). 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:
Design research survey: the Opted-in Research Participants database, from which the Wikimedia Design team will draw participants for design research sessions.
The Community Tech team will soon be posting their processes for evaluating and prioritizing work at mw:Community Tech team. The basic process for identifying high-priority tasks will be community-led and involve editors from as many projects as possible. This page is intended for brainstorming ideas, not prioritizing them.
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 Citoidservice 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.
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)[reply]
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.
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.
I don't believe so. Citoid is for automatic reference creation. RefToolbar is for (mostly) manual reference creation. Kaldari (talk) 17:13, 16 July 2015 (UTC)[reply]
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.
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)[reply]
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.
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)[reply]
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)[reply]
Discussion and support for this tool is [Wikipedia_talk:WikiProject_Medicine/Archive_52#Copy_and_paste_detection_bot here from Aug 2014]
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)[reply]
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.
Admin dashboard (shows edit wars, blocks, etc)
Create a dashboard on Tool Labs or a Special page that shows information especially relevant to admins.
It would be based on log and revision data from the MediaWiki database (or a mirror of the database). It would show recent blocks that had occurred. Kaldari (talk) 18:33, 16 July 2015 (UTC)[reply]
Bot to generate list of worst lead sentences on Wikipedia
Not sure how this idea would work? Based on what criteria? And why would we need a bot to do it? Users can simple go through articles. Lead sentences are really hard to write. Doc James (talk · contribs · email) 07:14, 28 May 2015 (UTC)[reply]
Support. Section watchlisting is a long requested and very valuable ability. This is clearly NOT Superseded by Flow, as Flow obviously doesn't work on non-Flow pages, and obviously can never work in Articlespace. Alsee (talk) 19:50, 16 September 2015 (UTC)[reply]
A nice disambiguator
See also: [[::es:User:Qwertyytrewqqwerty/DisamAssist.js|:es:User:Qwertyytrewqqwerty/DisamAssist.js]]
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)[reply]
It would be opt-in on a project-by-project basis; so WikiProject Medicine could decide to use or not use such a service. The exact criteria for receiving an invitation would have to be nailed down. In the meantime, my reports list editors on the basis of having at least five edits in a project area in a one-month period, regardless of how old that account is. harej (talk) 13:37, 27 May 2015 (UTC)[reply]
It sounds like something that would be good to study. It could be set up to send invites to half the people who made at least 5 edits and not to half (those who have been previously send invites would not get another)
This idea was piloted a couple years ago on Portugese Wikipedia (botrequest). I'm not sure what the outcome was, but it might be useful to get in touch with Alchimista or one of the other editors who was involved. Jmorgan (WMF) (talk) 23:16, 3 June 2015 (UTC)[reply]
On Portuguese Wikipedia is was used in a pilot project, it invited newbies to the local medicine project. I can't find retention stats, but if anyone find them usefull, i can get them. Alchimista (talk) 21:02, 23 June 2015 (UTC)[reply]
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.
I wondering if using google image search at the time of upload would be useful for creating an autodetection method? We would also need to build a whitelist to reduce false positives. Doc James (talk · contribs · email) 04:09, 22 May 2015 (UTC)[reply]
I agree. I think a good first step would be use perceptual hashing to see if a similar image was previously deleted. I imagine lots of copyvios are uploaded again and again. Bawolff (talk) 04:20, 10 June 2015 (UTC)[reply]
I could not find a Phabricator task for this request. I think it would be useful to have one, if someone wants to create it (#Possible-Tech-Projects?).--Qgil-WMF (talk) 07:51, 10 June 2015 (UTC)[reply]
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.
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.
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
We need a whole package of add ons (such as template and gadgets) that Wiki's can opt into and which are supported by the WMF. I love WikEd for example but it is not an option on many Wikis and thus if I want to use it I need to copy the content to En Wiki first. Doc James (talk · contribs · email) 04:08, 22 May 2015 (UTC)[reply]
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...
What are the top 5 wikiproject categories of articles User X has edited in their lifetime? In the last 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)[reply]
Agree these are excellent ideas. Some of this data is already available on an article by article basis such as here for gout [1].
And the rest of the data could be added to here [2]
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."
(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)[reply]
This goes absolutely to the core of our mission, so a project is a good idea but there is work done on it already. I'd be interested to hear from the WMF how much priority/work is given to decreasing page weight. Maybe it's already been set as a goal? As for talk pages, perhaps there isn't a technological solution: maybe users should be nudged/helped to archive more frequently? MartinPoulter (talk) 14:36, 27 May 2015 (UTC)[reply]
Yes with respect to talk pages the push likely needs to come from the community. Editors need to be informed that they do not own their talk page and that it is like all other pages to improve the encyclopedia. If people cannot post on yours as it is to long someone may archive it. Doc James (talk · contribs · email) 07:21, 28 May 2015 (UTC)[reply]
Are there any measures about page weight on Wikipedia. There is a load of one-time data about page structure and layout which is cached afterwards. Anything beyond is page content
A comparable project can be found under mw:ResourceLoader. Maybe it needs to be reevaluated.
@Guy Macon:: some of the subtlest and most crucial performance engineering is already being done by volunteers who optimize and refine Lua modules, so there is good precedent for editors making a positive contribution to site performance, and I'm happy to see this affirmed in your proposal. Could you elaborate a little on how you imagine this working out? What sort of things would you eliminate to reduce page weight? I suspect that the biggest impact could be made by conducting an audit of on-by-default gadgets and site JS / CSS across major wikis and doing some initial triage by ranking gadgets in order of size and popularity. This would be very valuable work, and you would definitely have partners for this work in WMF Engineering. I can elaborate further, but I want to stop and check with you if this is consistent with what you had in mind, or if I'm missing the mark. --Ori Livneh (talk) 21:45, 30 May 2015 (UTC)[reply]
┌─────────────────────────────────┘
I would love to help the WMF in any way that I can in this area.
Before I get into the details of what I have in mind, I want to make sure that everyone reading along understands that this only concerns number of HTTP requests a page makes and the total number of bytes sent to the browser (the page weight). It has nothing to do with how hard Wikipedia's servers have to work to generate those HTTP requests and bytes of data. The gold standard is low page weight on the first access to a page, but making it so that subsequent accesses get as much data from local cache instead of from Wikipedia's servers is also an important factor in reducing page weight. Also optimizing for mobile (optimizing for a small screen, no mouse/keyboard, low-power CPU, and moderately limited bandwidth) is not the same problem as optimizing page weight (optimizing for severely limited bandwidth and nothing else). I cannot emphasize this strongly enough.
The above is a good description of the general idea I have in mind, but I would go about it in a somewhat different way. First I would split the problem into two problems:
Reduce page weight without changing anything that is visible to the user.
Reduce page weight by changing what the user sees.
Work on the second problem should be delayed until we have done all we can to solve the first problem.
Next, I would look at a few of our most-accessed pages (especially the main pages at www.wikipedia.org and en.wikipedia.org) and analyze exactly how many HTTP requests and bytes of data it takes to display them. Do those gadgets and JS / CSS add a lot of bytes? Or are the images a larger problem? Is there any place where we can replace two HTTP requests with one? Measure first, then optimize where it does the most good.
I am going to break my own rule now and talk about optimizing the talk page you are reading. I am doing this because every time I bring this up someone inevitably says that Wikipedia is already doing pretty much all that it can to reduce page weight. I am not implying that the following should or should not be a high priority before we do the measuring I discuss above.
Even simple text-based pages such as this talk page can be optimized.
Consider the following snippet from the thread above:
[...] Maybe it needs to be reevaluated.
-- Menner (talk) 16:14, 30 May 2015 (UTC)
@Guy Macon:: some of the subtlest and most crucial performance engineering is already being done [...]
That's 180 displayed characters, plus whatever it takes to make the links, bold, etc. work.
The wikimarkup for the above is really quite compact:
[...]Maybe it needs to be reevaluated.
: -- [[User:Menner|Menner]] ([[User talk:Menner|talk]]) 16:14, 30 May 2015 (UTC)
:{{Ping|Guy Macon}}: some of the subtlest and most crucial performance engineering is already being done[...]
That's 225 characters, and you get the the links, bold, etc.
<dd>@<a href="/wiki/User:Guy_Macon" title="User:Guy Macon">Guy Macon</a>:: some of the subtlest and most crucial performance engineering is already being done [...]
Now we are at 406 bytes sent to the browser (ignoring compression for the sake of argument, because I would have to post what looks like random garbage above. When we do the measuring, compression should be taken into account).
So, can we reduce that page weight?
First. every line sent to the browser has a DOS-style carriage return and line feed (OD OA) as a line ending. If we used a Unix-style line feed (0A) that would save one byte on every single line of HTML on Wikipedia.
Actually HTML works just fine with both the carriage return and the line feed removed, but it isn't as readable for geeks like me who look at the raw HTML output. This is easily addressed by making the HTML line ending configurable in the preferences.
OK, how about that "title=" in the link? Can we get rid of that?
So right there we have a bunch of useless bytes sent to the browser for every signature. They have zero benefit to anyone. All they do is increase the page weight.
I could go on and on with other obvious ways to optimize this page without changing what the user sees, but again, the first step is to measure the page weight of various pages and identify where we will get the most benefit for the least effort.
I am open to help WMF in any way that I can in order to make this happen. I will tell you, though, that measurable goals and a schedule are non-negotiable. I have worked on too many engineering projects to let my name be associated with a project that lacks measurable goals and a schedule. See [ http://www.guymacon.com/structuredengineering.html ] for some reasons why. --Guy Macon (talk) 08:40, 31 May 2015 (UTC)[reply]
You are presenting data that (correctly) claims that for those of us in the first world with adequate internet bandwidth there are more important things than HTML requests and byte counts, but you have completely failed to address my argument that in rural third-world areas with severely limited bandwidth high page weight makes websites completely unusable. Try using a 1200 baud dial-up modem with its typical 300ms latency to connect to the Internet and see how you like trying to access websites with a high page weight. --Guy Macon (talk) 19:38, 31 May 2015 (UTC)[reply]
It isn't true. In urban third-world areas the Internet is basically accessed with mobile devices. Once you get out of the range of cell phone towers and (relatively) high incomes, the Internet is largely accessed by a village-full of obsolete laptops all sharing a single Wifi connection with an extremely limited-bandwidth connection to the rest of the world. Read the Page Weight Matters essay at the top of this thread. Those Youtube users almost certainly were not using phones to access the net. Low bandwidth Wikipedia access and mobile Wikipedia access are two separate problems. Mobile has somewhat limited bandwidth, small screens, no keyboard, and slow processors designed to extend battery life. Low bandwidth has extremely limited bandwidth, with typical older laptop screen size, processor and keyboard/mouse. --Guy Macon (talk) 00:32, 8 July 2015 (UTC)[reply]
This doesn't sound like it's in the scope of the Community Tech team. I believe Ori has been working on this recently, though. Kaldari (talk) 18:01, 7 July 2015 (UTC)[reply]
Is that a personal opinion or are you speaking on behalf of the WMF? And can you point to the description of exactly what would be "in the scope of the Community Tech team"? Oh wait, there isn't one. Didcot power station (talk) 19:19, 7 July 2015 (UTC)[reply]
This is just the standard WMF stonewalling technique. When anyone posts any sort of proposal -- even in places specifically designated as being for proposals -- a WMF employee tells him or her that it was posted in the wrong place with no indication as to where the right place might be. Sometimes, just for variety, they suggest another place and then you get stonewalled when you go there. Its all very predictable after you have experienced it a half a dozen times. --Guy Macon (talk) 00:32, 8 July 2015 (UTC)[reply]
Indeed, it is just two years since this was illustrated at MediaWiki [3]. And every time it happens it demonstrates that this "Community Tech" process is a sham. We were told recently [4] by a WMF employee that "no WMF employee will say much on behalf of the Community Tech team before the Community Tech team lead is hired and announced". Yet Kaldari, a WMF staff member, tells us what the scope of the project is. So I challenge them, give us some reason to believe that this project is not a huge sham by publishing the scope here and now. No real project would be set up and staffed without someone, somewhere, having a clear idea about scope. If there is a scope, publish it. If not, why not, and why is he trying to put off volunteers by making guesses about what it might be? Didcot power station (talk) 06:47, 8 July 2015 (UTC)[reply]
If we want this page to be useful, we need to add ideas... but also remove them when they can be addressed better elsewhere. Reducing page weight fits squarely within the scope of the Performance team lead by Ori Livneh, who added a comment above. This interesting proposal is getting into deep details, and it deserves a more productive context for discussion and work than a segment in a huge wiki page with many unrelated updates. I have created phab:T105136. There you can subscribe, capture what matters in its description and you can find or create subtasks, blockers, related tasks.--Qgil-WMF (talk) 11:11, 8 July 2015 (UTC)[reply]
Frequently Unanswered Questions about this proposal
Line feed
Frequently Unanswered Question # 1:
In the HTML that Wikipedia sends to the browser, every line sent to the browser has a DOS-style carriage return and line feed (OD OA) as a line ending. If we used a Unix-style line feed (0A) that would save one byte on every single line of HTML on Wikipedia. Actually HTML works just fine with both the carriage return and the line feed removed, but let's just discuss (OD OA) vs (OA) for now. We could do this by making the line ending configurable in nthe preferences with the default (OD OA) and (OA) an option, then after we are sure there are no bad effects, change the default. Why am I unable to get anyone at the WMF to discuss the merits of doing this? --Guy Macon (talk) 00:26, 8 July 2015 (UTC)[reply]
So right there we have a bunch of useless bytes sent to the browser for every signature. They have zero benefit to anyone. All they do is increase the page weight. Why am I unable to get anyone at the WMF to discuss the merits of doing this? --Guy Macon (talk) 00:26, 8 July 2015 (UTC)[reply]
There are gadgets/user scripts that rely on that. Mostly because a link can be a redirect. Navigation popups uses this for instance. Perhaps we can output them only when there are redirects, but still those scripts relying on it's presence will break. —TheDJ (talk • contribs) 21:55, 12 July 2015 (UTC)[reply]
Access talk pages in the mobile interface from main article.
Currently, there is no way to access an article talk page from an article, unless you type the talk page name into the search bar or the article has a wikilink. Perhaps there could be a "talk" button, akin to what we already have on desktop wikis? Chess (talk) 17:29, 25 May 2015 (UTC)[reply]
This is partially intentional left out though. A wikitext editor on mobile is a very confusing and unusable interface unless you are already able to use it... Just encountering it already seems to scare people. I think adding such a button right now would negatively impact the quality of the mobile website. We need to find a better interface first. —TheDJ (talk • contribs) 07:38, 27 May 2015 (UTC)[reply]
Have you tried commenting / editing in Flow pages? It's not that bad already today. While there is not much precedent about writing encyclopedias and books on mobile devices (although even this is changing), by now there is a big load of prior experiences on mobile discussions, as seen in social media and blogs. Promising, at least for lighter discussions.--Qgil-WMF (talk) 08:47, 5 June 2015 (UTC)[reply]
This is me working on librsvg. I've fixed five long term bugs in five days. SVG is everytime a problem when I draw a scientific graphic. Detailed analysis isn't done yet. Currently I'm trying to get some important fixes into latest gnome release before next freeze. Anything else would mean years of waiting. -- Menner aka 2A02:810D:1740:1554:D50D:D2D:256C:10D417:49, 27 May 2015 (UTC)[reply]
+1 It is absolutely annoying, time and resource wasting for everyone is willing to share SVG. Take simply a look on Commons, many SVG have an flooded crappy file-history (and then sometimes unused and dead or replaced by pixel-graphics). ↔ User: Perhelion13:24, 3 July 2015 (UTC)[reply]
SVG Help Button
Besides improving SVG rendering it would be useful to have a "SVG Help Button". Like the Media Viewer button it could be placed below SVG files on Commons media meta pages visible only for loged-in users. Because SVG itself as a non-WYSIWYG format has many pitfalls, it is important to give guidance to contributors.
Until end of 2015 I'll make a prototype with an idea of its look and feel based on user scripts.
Add ability to create own branch of page and ability to merge that version into main history (main branch). This would help to avoid most of edit wars and make comparing of different versions easier. --AS (talk) 10:13, 27 May 2015 (UTC)[reply]
I mean ability for a user to create a version (something like non-stabilized version in FlaggedRevs, but with few parallel versions, because there could be conflicts in non-stabilized version). For example a non-admin user can suggest a change for Main page, and if the change is ok, an admin just merges the version, without forking a page, copy-pasting etc.
It would be nice to have at least next abilities (which don't need core changes):
ability to fork page. Create a copy of page in personal namespace with one click and some magick to not include the page into categories. Why: for experiments and for users forbidden to edit particular pages.
ability to see diff of different pages. As I understand, there is currently no fast way to see diff of a fork and original page.
ability to partial reverting. During editing, when I see last diff, would be nice if I could just click some "revert" buttons next to particular chunks in diff so it would revert corresponding text in textarea. So I don't need to jump between diff and text to revert some changes on a page. --AS (talk) 14:02, 27 May 2015 (UTC)[reply]
This would greatly complicate the process of article editing, steepening the learning curve, at a benefit only in very specific cases. It looks like an attempt to solve with technology a problem that should be solved socially. As for copying a page to personal namespace, just copying and pasting the wikicode will do: it's not a hard task that urgently needs simplifying. I share User:MER-C's concern that making it easier to create user drafts will lead to many mor stale drafts. MartinPoulter (talk) 14:30, 27 May 2015 (UTC)[reply]
„This would greatly complicate the process of article editing, steepening the learning curve“ — this way of editing would be optional. „It looks like an attempt to solve with technology a problem that should be solved socially“ — imho, for now we are solving with social conventions a problem that could be solved with both technology and conventions (and we should delegate as much problems to technology as possible). „making it easier to create user drafts will lead to many mor stale drafts“ — why stale drafts could be a problem (how many is too many)? --AS (talk) 16:25, 27 May 2015 (UTC)[reply]
1) no fast way to compare (to preview diff of) sandbox with original page and with other sandboxes. 2) no ability for other person to merge my changes with saving of authority, so I'll be mentioned as author of the version (smth. similar to stabilizing version in FlaggedRevs). --AS (talk) 11:20, 28 May 2015 (UTC)[reply]
One just copies the current article into the sandbox hits save and than uses history to view the dif. One can state who the author is in the edit summary. I do this all the time when I edit in other languages and add content written by other people. Doc James (talk · contribs · email) 11:31, 28 May 2015 (UTC)[reply]
„uses history to view the diff“ - with original version, not with current version of original page (if I understand correctly). „One can state who the author is in the edit summary“ — that should be avoided if possible. --AS (talk) 08:57, 30 May 2015 (UTC)[reply]
It would be great to have some storage for pages metadata. For example, there are different projects in wikipedia, and currently status and priority of an article within a topic are stored on talk page in templates like en:Template:Vital article. It would be easier to manipulate and analyze such data if it is stored in something like Wikidata. But this data is helpful only for specific wiki, so thats my idea: local Wikibase for each wikimedia project! --AS (talk) 16:42, 27 May 2015 (UTC)[reply]
Improve talk pages editing
I'm not sure how to migrate existing talk page to something like mw:Extension:Flow, but it would be helpful. Current page-like-editing is not user-friendly for newbies :( --AS (talk) 16:51, 27 May 2015 (UTC)[reply]
Some years ago, the community identified four desirable improvements to talk page editing, all of which can be done in MediaWiki using Wikitext (and hypothetically could be extended also to VE editing). They are:
automatic signatures on talk page entries (easily done, we have bots that do it now - Flow automatically appends the username, not the user signature)
a button on the editing toolbar to automatically and correctly indent a post in a discussion and automatic outdenting after a certain number of indents (both also fairly easily done - on last looking at Flow, the indentation scheme made most threads almost unreadable)
more graceful edit conflict management (significant work on this has already been done - this is the only thing Flow is better at, but that is because it literally creates a new page for each entry)
ability to watchlist an individual thread or discussion (this is a challenge for wikitext, but Flow's current solution seems to be that you have to watchlist individual threads on a 'page' in order to see changes to that thread, which essentially deprecates watching entire 'pages')
It escapes me why we have gone on to create a *third* user interface that new users would need to learn in order to be full participants in their editing communities. (In fairness, VE is optional on most projects.) Even if Flow was fully implemented on all talk pages, users would still need to use wikitext for a large number of workflows such as deletion discussions (where Flow would actually impede the work with its method of data storage), many discussion boards, requests for comment, requests for adminship, and dozens of other places. Adding another user interface adds complexity, it does not make things easier for new users. What it does is marginalize them, because it makes it that much harder to learn how to participate in almost all of the areas where input from community members is important. If it weren't for the fact that VE prevents people from adding signatures (and blocks a few other key wikitext functions), I'd say just go with permitting VE on talk pages. In fact, I think it would be fiscally more efficient to figure out how to add these features to VE dependent on namespace, rather than invest further in Flow. Risker (talk) 22:26, 23 July 2015 (UTC)[reply]
I think this is one of the points where exposure of the WMF software development roadmap to the community would be useful. Currently the Flow Portal shows the roadmap ending at 2014-15 Q4, ie at the end of last month. (I may say that the paragraph there beginning The roadmap items that appear below are guesses does not exactly fill me with confidence.) Questions have been asked of the ED as to her plans for Flow, but that discussion remains unresolved. It is hard for the community to make sensible proposals for improvements or new features if it is not told what the software base is expected to be, nor what the design criteria are, nor when, if ever, it is to be delivered. Rogol Domedonfors (talk) 10:16, 24 July 2015 (UTC)[reply]
Hit counter extension
MediaWiki no longer includes hit counters in core, following a request for comment, which means that Special:PopularPages and the "Most Viewed Pages" section of Special:Statistics are now removed. The hit numbers, which occurred until the 1.25 upgrade was installed, will still be kept in the database, but they will no longer be updated. It is planned to re-implement this functionality in an extension.
How is this relavent to community tech. The hitcounter feature was not used on wikipedia, and is inherently unsuitable to the architecture that wikipedia (and other wikimedia wikis) use. Thus its not in scope of the community tech team, at least as I understand their scope. (However, to answer your question, User:MarkAHershberger was working on this I believe). Bawolff (talk) 04:18, 10 June 2015 (UTC)[reply]
There are currently two mechanisms to stop a user editing an article on Wikipedia - protect the article so nobody can edit it, or block the user so they can't edit anything. That's it.
I really feel quite strongly that we need something in between those two extremes - the ability to protect or block a specific user from a specific article. It would allow topic bans to be enforced technically, and prevent editors from going towards a specific area of disruption while still accomodating them as much as possible elsewhere. We need editors, and sometimes we just have to take what editors we're given, and manage the disruptive elements.
Take a look at ANI on the English Wikipedia or read any discussions that involve a block and see how much drama that is - anything that can reduce that is welcome in my view. I've hacked a local installation of MediaWiki I maintain to allow "automatic G7" ie: any user (not just admins) can delete any page that they created, so I'm sure it's technically doable. Ritchie333 (talk) 13:02, 29 May 2015 (UTC)[reply]
Occasionally one both needs to both protect the article and than continually block new socks as they are created :-) It is to easy to get around this. You just keep creating socks. Getting them auto confirmed and editing around the semi protection. We have a few people who do this. Not sure what the solution is. Doc James (talk · contribs · email) 13:20, 29 May 2015 (UTC)[reply]
+1. We are currently using AbuseFilter for personal restrictions, but native solution would be better --AS (talk) 13:50, 9 June 2015 (UTC)[reply]
Statistics on gadgets usage (number of users like for beta-functions). It is currently unclear, which old gadgets should not be maintained anymore. --AS (talk) 09:26, 30 May 2015 (UTC)[reply]
I think, that beta features and gadgets are quite different story, but yes, it would be nice for developers to see, which gadgets are used more (are more popular), so they can be developed more. --Edgars2007 (talk) 07:27, 31 May 2015 (UTC)[reply]
For me "enhanced editing toolbar" is useful only because of code editor, so I'd like it to be enabled for me only in case I'm editing lua/javascript/css page --AS (talk) 09:31, 30 May 2015 (UTC)[reply]
A code editor appears whenever you want to edit a Lua / JavaScript / CSS page regardless of your "enhanced editing toolbar" preferences, isn't it? I believe this is true at least in mediawiki.org.--Qgil-WMF (talk) 08:34, 9 June 2015 (UTC)[reply]
No, the code editor is part of the enhanced toolbar (integrated into the WikiEditor extension). Disabling it will disable the code editor. Bawolff (talk) 04:12, 10 June 2015 (UTC)[reply]
KML files are used in en.wikipedia to display route maps (eg roads, train lines, and other linear features) via w:en:Template:Attached KML (see d:Q6690822 for the equivilent on other wikis). Currently this is achieved by storing the KML files as text in subpages of the template (transclusion count for en.wikipedia), which is sub-optimal for multiple reasons:
There is no associated {{information}} template, for description, author, date, licence, information source, etc.
The licence is restricted to the standard licence for a wikitext page, rather than being able to choose a different licence such as CC0 or CC-BY
Categorisation is difficult, as including [[Category: ]] links at the end of the page breaks the KML file.
The KML files serve only one wiki – they cannot be shared with other wikis, nor associated with the relevant Wikidata item.
Yurik talked about it briefly during his tech talk (in the form of interwiki transclusion). Interwiki transclusion is kind of a big thing. Allowing vega json files to be uploaded to commons would be a simpler approach but has its own pros/cons. Bawolff (talk) 00:55, 13 June 2015 (UTC)[reply]
The "Attached KML" scheme as it stands presents puzzles to unlucky readers of articles offering them. If the "KML file" option is clicked on, no actual .kml file results, instead a file index.php is presented for download. Such a file type is simply ignored by Google Earth, unless it is renamed to index.kml for example. Via Firefox's interface, there is no option to rename this file before downloading. Further, windows systems are often set to not show the file's "type" (and installation policy choices may prevent a user changing that setting), so users of IE8 (which does offer a file rename if the file is to be saved) may still be stuck. As .kmz files are much more compact, the same convenience would apply. Some browser/server exchanges can agree to engage in file compression, but having the source file definitely compressed would be more direct. NickyMcLean (talk) 10:38, 17 June 2015 (UTC)[reply]
To add some numbers, the Attched KML templates across the various language versions of wikipedia have over 9800 transclusions combined, the largest of which are en.wikipedia (8341 transclusions, and template-protected as a high-risk template) and cs.wikipedia (1062 transclusions). - Evad37 (talk) 05:45, 25 July 2015 (UTC)[reply]
This extends the autoblocker such that a cookie is placed when a user is blocked, and triggers the autoblocker when such a cookie is detected. This impedes shifting IPs (sometimes unintentionally) to evade blocks. MER-C (talk) 01:50, 8 June 2015 (UTC)[reply]
I have been contributing to nl.wiktionary for a long time and I am now trying to overhaul the en.wikibook Dutch that I wrote a long time ago and I am very frustrated at how primitive and inadequate wikisoftware is when it comes to interactivity, even such passive interactivity where readers can push a simple button to hear the pronunciation of a word.(Let alone the kind of interactivity of websites like Memrise or Quizlet, I'm not even talking about that. In fact instead I send my readers to Quizlet to go practice there, because I don't have much hope that wiki will ever be able to do what they are doing.)
First of all it took years before it became even reasonably feasible to upload pronunciation files to commons. Luckily that has been streamlined enough that there is a treasure trove of sound files there. But now the question is whether you can actually use them. The only way that I have sound that comes even close to what I need to let people learn some language from my page is
[[file:nl-geweldig.ogg|noicon|40px]] geweldig
resulting in
geweldig
All other templates like audio etc. either result in something HUMONGOUS or in something that abducts my readers away from the text I want them to read while listening, to some primitive black screen.
Even the simple arrow as above has its problems. It is still too big and it does not match the size of a line of text. It cannot be used inside a piece of text and the only way I have found that suppresses the automatic line feed is to put in "left"
Unfortunately, you can only do that once, otherwise you get a mess
noicon geweldig noicon geweldig
So, the logical thing would to put it in a table, but look what happens inside a collapsible wikitable, which apparently doesn't work here, so please follow me to the french wikibook and open the two boxes saying "Solution" to see what I mean. Also look at the convoluted way I put all my arrows in. It was necessary, I assure you otherwise the mess is even greater. I spent an hour trying to defeat this wonderful software..
So my tech idea? To actually start worrying about how primitive this wonderful software is. Am I insulting you with that? Then please look around on the internet and you will find videos that start whether you want them to or not or websites that suddenly start talking to you and ask for your input. You don't even have to push a button...
To be honest, it was difficult to understand what your actual complaint was (Other then that our support for audio/video multimedia sucks, which I think everyone agrees with). After reading a couple times, you basically want an inline play button for audio files, in order to make something more like:
In a very short time, it's become clear to me that many admins need help dealing with IPv6 rangeblocks. See this and [this for example. Can the WMF come up with better tools, scripts, or at least more understandable documentation to help out? I looked at the MW docs and there are no practical examples admins can follow. --NeilN (talk) 18:19, 11 June 2015 (UTC)[reply]
I'm not sure what global filters are, but I think I mean different thing: be able to declare a variable, which would be available in each filter. --AS (talk) 10:13, 18 June 2015 (UTC)[reply]
Edit summaries are currently limited to 255 bytes. This is a pain for non-English editors, where one UTF-8 character consumes at least two bytes. MER-C (talk) 06:29, 3 July 2015 (UTC)[reply]
Now that SUL finalization is complete, there is no longer an obvious obstacle to developing a proper cross-wiki watchlist. This is a very old request (phab:T5525 from September 2005) and has been cited as one of the reasons why users on, say, Wikipedia are reluctant to branch out and participate on Meta, Commons, etc. There has been an effort to develop this as an external OAuth tool (phab:T92955), but it really should be developed within MediaWiki itself, dovetailing in with the existing Special:Watchlist page in some manner. This, that and the other (talk) 10:05, 17 July 2015 (UTC)[reply]
History pages are a key tool for article maintenance! Some possible improvements:
More reliable layout; clearer divide between rows, and/or better wraparound behaviour
Better separation of data from actions. "Data" includes revision links, timestamp, user info, edit summary, tags, et cetera. Actions include rollback, undo, thank, et cetera.
Fewer mildly-cryptic things that might be confusing to newbies. For example: "cur" and "prev" links aren't self-explanatory as "diff with current revision" and "diff with previous revision", respectively.
Visual representations of data. For example, graphical links between net-null revisions (usually between a revert edit and the revision to which it reverted). The key idea here is "information on history pages that doesn't require reading words or numbers", so that it's easier to understand a page's history at a glance.
I've played around with some of this already using JavaScript; interested parties can paste importScript("User:Nihiltres/nothingthree.js"); and then nothingthree.customRevs.testRun(); into the console of an English Wikipedia history page to see how my experiments ended up. For example, I make the byte-difference more self-explanatory by changing "(65,176 bytes) (+1,234)" into "+1,234 → 65,176 bytes".
I stopped messing around a) because it was tiring and b) because this is something that should be implemented in MediaWiki proper, rather than reimplementing the whole damn history page in JavaScript. Maybe something the Community Tech team would like to take a run at? {{Nihiltres|talk|edits}}20:25, 17 July 2015 (UTC)[reply]
Develop tools to convert Flow and LQT pages to normal talkpages
In the not too distant future the Flow project will be abandoned and people will be forced to admit that it failed (just like LQT). When the inevitable happens, we need to have a way to convert the messy and unreadable Flow and LQT pages back to talkpages. The Quixotic Potato (talk) 05:46, 21 July 2015 (UTC)[reply]
This is a Community Tech team task. Perhaps contributors could comment here or at the Phabricator page with suggestions for the most burdened classes of Wikimedians. What technical tools would be helpful? Rogol Domedonfors (talk) 06:35, 26 July 2015 (UTC)[reply]
JS scripts without import
It would be nice to have special area where JS scripts can be placed. That could be a namespace like script: and only users with assigned rights can edit them. This scripts will be executed by every visitor of that page.
In a more relaxed scenario these script pages might be embedded into common wikipages like templates similar to LUA.
The advantage over imported commons:COM:User Scripts is that it requires no obscure technical methods before the scripted features can be used.
An example might be to realize advanced search bars, special upload tools, diffrent kind of calculators, template filling forms with wikitext generator or in my case a replacement of commons:com:SVG Check and maybe other tools that currently require specific wmf tool server.
For a variety of reasons many of the special reports have become useless and some projects have been forced to create their own custom reports such as database reports or through means of the WMFLabs/Toolserver. I recommend a complete overhaul be done to the way these reports are generated that would allow some role within a user community (like Admin or template editor) to be able to modify the code that drives these special pages. Some functionality I think would be useful to do should include:
The ability to hide reports from the list of those displayed if they aren't relevant to the project
Add new reports under some type of custom section
Be able to modify the criteria that is used to generate the reports.
Have more flexibility to expand the length of a report even if that is to break it into 1000-2500 article chunks across multiple pages.
Of course this is just a short list and more detailed requirements and analysis of the problem would be needed. Some things have already been suggested here as minor changes to individual reports or other utility changes but what is really needed is a complete overhaul of the way the Mediawiki system creates and handles reports. Reguyla (talk) 14:48, 26 August 2015 (UTC)[reply]
Most of the QueryPage special pages run very expensive queries on the database so it is not a good idea to let users on wiki modify them. But we should investigate ways to let the pages more flexible (i.e. options in the form). --Glaisher (talk) 17:16, 26 August 2015 (UTC)[reply]
Thanks that's good to know. I think I heard that about the queries and maybe as part of the investigation we could see if its possible to make some of them run with less resources. Its also possible some aren't needed at all and could just be eliminated completely or turned off. For example, Pages without language links is pretty irrelevant for Wikipedia now (although some Wiki's may use it) so maybe that could be an example of one we disable and don't run. Does anyone really use Dormant pages or Orphaned pages? My guess is probably not. Reguyla (talk) 17:33, 26 August 2015 (UTC)[reply]
Technical user right to edit summaries
The user right to edit summaries. For example, I've made an edit in some Lua-module but forgot to leave an explanation of the change for other developers. --AS (talk) 11:42, 18 September 2015 (UTC)[reply]
Done This is done. Kaldari (talk) 17:55, 7 July 2015 (UTC)