Wikimedia Meta-Wiki

Community Wishlist Survey 2019/Status report 1

< Community Wishlist Survey 2019
(Redirected from Community Tech/Status report for 2019 wishlist)

Hello, everyone! In this update, we will share the status of all remaining 2019 Community Wishlist Survey proposals, as well as what we’ve worked on since the last status report. Since the last report, we have focused on many exciting projects. Some of these projects were quite large and complex, but we enjoyed the challenge, and they have helped us grow as a team. We also dealt with the emergence of a global pandemic, which impacted us (as it has many people), and slowed down our progress to a certain extent. However, we were still able to get a lot done, and we look forward to sharing what we’ve accomplished.

This report is divided into a few sections. First, we’ll share what we’ve done since the last report, which is a combination of 2019 wishes, 2017 wishes, and our first 2020 wish. Then, we’ll share information on the 4 wishes that we have declined from the 2019 wishlist and why. For each of the declines, we made the decision after careful analysis. It should also be noted that, in the past, some of our wishes were taken on by other teams (such as 2 wishes in the 2017 survey). However, that isn’t the case anymore; we needed to do all of the wishes ourselves. For this reason, we needed to be honest and realistic about what we could accomplish.

Finally, we’ll share 2 wishes that are eligible to be voted on again in the 2021 Community Wishlist Survey. We have a new survey format this year, which will be explained in greater detail in the Community Wishlist 2021 page (to be published very soon). Briefly, the main idea is that we’ll have one backlog per year. This means that, each year, the backlog gets voted on and reprioritized. This way, we can ensure we're always working on the highest impact wishes. We also won’t have the concept of “top 5” or “top 10” anymore. This way, we will no longer be committing to a potentially unrealistic number of wishes before being able to fully analyze them. The end result is that all volunteers will have a more accurate and complete picture of what we can accomplish in a year. The survey structure will largely remain intact, but these two changes will help sustain and improve the wishlist process. You can expect more updates in the survey page, which will be coming soon.

Overall, we thank everyone for their feedback, insights, and collaboration. We look forward to seeing proposals—both old and new—in the 2021 Community Wishlist Survey!

What we did edit

Page Curation & New Pages Improvements edit

This was #1 wish from the 2019 wishlist, which included 19 separate wishes to improve the workflow of NPP. This was a huge project, which involved 7+ months of work. We released 17 changes that fulfilled 13 separate requests. For each of the 6 requests that we could not fulfill, we shared our rationale and findings. Overall, we dedicated substantial time and resources to this project, and we collaborated with many community members. We learned a great deal about New Pages Patrol and the important work they do. We hope this suite of improvements has helped them work more efficiently and with greater ease.

Password Reset Update edit

This was #3 wish from the 2019 wishlist. We released a new feature, called Enhanced Password Reset, which improves privacy and helps prevent harassment. With this feature, you can optionally check a box in Preferences that says “Send password reset emails only when both email address and username are provided.” If the box is checked, you can reduce harassment through unsolicited password reset emails. This can be set as a local or global preference. During this project, the team issued technical and security improvements to the password reset process, in addition to implementing the feature. We also wrote documentation on password resets to help clarify the experience for all Wikimedians.

Ebook Export Reliability edit

This was the #4 wish from the 2019 wishlist. The project aimed to improve reliability of WSExport, which had frequent issues related to errors and downtime. By the completion of the project, we recorded 179 minutes of downtime in a two week period, compared to 941 minutes of downtime before the project. We also recorded 99.42% uptime for WSExport after the completion of the project. Following this work, in the 2020 survey, the Wikisource community asked for additional improvements. The team has already conducted research and community consultation for this new Wikisource project, and early development work has begun (more details on that project below).

Watchlist Expiry edit

  • Project page
  • STATUS: Release in progress (primary engineering work done)

This was the the #7 wish from the 2019 wishlist. The watchlist expiry project aims to provide a short-term watchlist option to users. With this change, users will have the option to watch pages for a short period of time, rather than indefinitely. This was a very large and complex project, which has been requested since at least 2006. We knew this project would be time-consuming, but we felt that it was an important feature with strong community support. For these reasons, we spent much of 2020 working on this feature. The primary engineering work is now complete and the release process has begun.

Who Wrote That? edit

This was the #4 wish from the 2017 wishlist. In our last status update, we wrote that this was one of the hardest projects to come out of that year’s survey. Fortunately, we could use the WikiWho service, which enabled us to make it possible. This project still presented challenges, as many edge cases and user interface issues surfaced, but we were able to resolve the high priority ones. We released the feature as a browser extension for Chrome and Firefox users. WWT is a handy tool, and it was a great experience to design and build it. You can read documentation at Mediawiki.org.

SVG Translate edit

This was the #9 wish from the 2017 survey.  With this project, we aimed to build a Toolforge tool that would allow users to to translate SVG files into local languages. Users could then upload these translated files onto Commons. We are pleased to share that we built a new tool for this project, after receiving community feedback in the research and development process. You can find documentation on the tool at the SVG Translate tool page on Commons.

Ebook Export Improvements edit

This was the #1 wish from the 2020 survey. With this project, we aim to further improve reliability of the WSExport tool. In addition, we aim to improve support for underrepresented languages and to improve the overall user experience of ebook exports. We have already conducted research and analysis, which included the initial project launch in May and a status update with specific proposals in August. The engineers have begun early work on the project, based on the proposal shared in August. Another status update will be coming shortly, focusing on proposed user experience changes. The team will primarily focus on this project for the next few months.

Declines edit

Night Mode edit

After careful consideration and multiple rounds of internal feedback, we have decided to decline this project. We know that dark mode can be an important tool for people, as it provides comfort and support to readers and editors at night. However, this project presented multiple challenges, which we will explain below. We have also provided workaround solutions for people who are still interested in using a Dark Mode on wikis.

Rationale: We began our analysis with the genuine hope that we could deliver a dark mode experience. However, as we began to dig into the project, we began to identify some significant risks. First, we would need to accommodate a large range of user preferences and use cases, which added a high level of complexity to the project. This included robust support for all devices and skins used by Wikimedians, in addition to handling images, graphs, and maps. This work alone would require a large amount of time and resources.

Second, we identified major technical concerns, which were as follows: When you are a reader on Wikimedia wikis and you access a page, you usually don’t hit our server layer. Rather, you hit the caching layer. This means that, if we were to implement Dark Mode, we would need to set up the stylesheet to Dark Mode and know to send it to the people who want it. We could do this in two possible ways. In the first option, we could send the stylesheet to everybody, which we would make conditional (i.e., light and dark mode for everyone). This would mean that it would be cached and the browser would decide what to display. Consequently, we would need to invalidate all of our cache and we would need to ship a larger payload. As a user, you would have double the styles that you need, and we would be creating larger cache servers. This is a less than ideal technical approach, which we wouldn’t feel comfortable taking on. In the second option, we could do this work with a gadget. With this method, you get a cache after it loads. However, this approach gets the JavaScript, which causes the page to flash upon each page load. This is a less than ideal user experience, and it could not be a long-term solution.

Third, the Desktop Improvements work has already begun. For this reason, it doesn’t make sense for us to work on infrastructural improvements to the user experience. While the Desktop Improvements work does not impact all skins, it will impact Vector, which is used by a large share of users, and Dark Mode should be compatible with the New Vector skin. This means that a Dark Mode project should be worked on after the completion of the Desktop Improvements work, most likely.

In total, the project was too large for us, due to the plethora of technical and user experience challenges. This wish needs significant research and engineering resources, which are beyond our resources and capacity. For these reasons, we have decided to decline working on this product.

Workarounds: There is Dark Mode, a user script created by Volker. There is also Nightpedia, a user script created by MusikAnimal, which achieves dark mode by inverting colors on the wiki. You can easily install it on all wikis or just some wikis, and you can easily toggle between a “day” mode and “night” mode. The main issue with both scripts is that there is a flash between page loads (which goes back to the technical challenge described above). Despite this limitation, Dark Mode and Nightpedia can be very useful to some users, so we recommend you check them out.

If you use the Wikipedia app, you can enable Dark Mode via Settings > App theme > Dark.

There are also many free browser extensions, software solutions, and mobile apps for “Night Mode” or “Dark Mode.” These extensions, products, and apps can create a dark mode experience for Wikimedia wikis, as well as other websites. This can be a quick solution for those who want a more robust Night Mode option that can handle a variety of use cases, both on and off wikis.

Conclusion & next steps: We want to thank everyone who participated in developing the wish proposal and the voting process. While we were unfortunately unable to fulfill the wish, we are happy that other solutions are available. Thank you again!

Put mw.toolbar back edit

After analyzing this wish as a team, we have decided to decline this proposal. Below, we have explained our rationale for this decision. We have also provided workarounds for people who want to access functionality previously found in mw.toolbar.

Rationale: This wish proposed that the team restore mw.toolbar. To provide a bit of background, the Editing team removed mw.toolbar from Mediawiki core (also known as the 2006 wikitext editor) in 2018. This was because the 2010 wikitext editor had become the new standard, so WMF would no longer be officially supporting the old mw.toolbar. Some editors were concerned about the effects of this removal. The older toolbar had specific gadgets and tools that were very important to editors, and some of these tools were not found in the other wikitext editors' toolbars. Separately, the German-language Wikipedia and a few smaller wikis had tied the visibility of the Extension:CharInsert, which is important to many editors, to the existence of mw.toolbar 2006 editor.

We have declined the wish for two reasons. First, the problem with admins tying the CharInsert extension to mw.toolbar has been fixed locally. Most editors who supported this wish were seeking the CharInsert extension, not mw.toolbar itself. This update resolves many of the issues related to compatibility and convenience that were raised by the deprecation of the 2006 editor and replacement with the 2010 editor.

Second, some wikis can access the old toolbar via gadgets. For example, on English Wikipedia, there is a way to install the Legacy Toolbar (which is used by 1200+ accounts on English Wikipedia, as of October 2020). For German Wikipedia, you can check out "Bringt die Bearbeitungsknöpfe des Quelltexteditors zurück (der sogenannte 2006-Editor)" in gadgets. One can find links for similar gadgets for other language wikis at the Removal_of_the_2006_wikitext_editor page on Mediawiki.org. If your wiki does not have such a gadget, we encourage volunteer developers to build such tools.

Third, it is the policy of the Community Tech team to not undo the work of other teams. The decisions made by other teams are ones we take seriously and that we respect. If volunteers have issues with decisions made by other teams, they can certainly advocate for change. However, that should be done through direct communication with the team in question. Furthermore, we are happy to improve tools and experiences developed by other teams, but we do not directly reverse decisions. Instead, we feel that it is best to find a common understanding, which takes into account the full history of the product. In this case, since an update has already been made, we feel that the original issue has been addressed, and further concerns can be brought to the Editing team directly.

Workarounds: For users who want to use the old editor, they can see if one of the legacy editor gadgets (as described above in "workarounds") is available for their wikis. For editors who want an improved editor experience, we recommend that they examine the current state of the 2010 or 2017 wikitext editor. Recommendations for improvements can be made directly in Phabricator and shared with the Editing team.

Conclusion & next steps: We thank everyone who shared this wish with us. It helped vocalize some of the changes that needed to be made to wikitext editors moving forward, and we look forward to seeing how wikitext editors continue to improve in the years to come.

Article Reminders edit

After analyzing this wish as a team, we have decided to decline this proposal. Below, we have explained our rationale for this decision. We have also provided workarounds for people who would like to be reminded about particular articles or editor processes.

Rationale: This wish proposed that the Community Tech team create a reminder system. This proposal was brought up for many use cases, such as: keeping track of articles that require check-ins, being reminded of events, and being reminded of conversations to follow up on, among other cases. One proposal was that a new screen could be available under the “More” menu, which would enable users to pick a specific date to receive a reminder. The reminder could then be sent to the user via the Echo notification system. We have seen interest in a reminder system of some sort for years, with tickets created in 2015 and 2017, among other times. For this reason, we wanted to see if it was possible to do this wish.

However, as we began to analyze this wish, we identified three significant challenges and risks. First, we found that the technical work to set up article reminders was quite complicated. It would require that we set up a queue of events. In other words, this would be something in the server that has a queue of events that runs on demand. There is currently no infrastructure for this currently in place. This means we would need to build the whole queue system ourselves. To do this work is not all trivial. It would be a very large technical project, which is beyond the available time and resources of the team.

Second, even if such a system would be built, the Community Tech team would not be the team to build it. This project would need to be the work of the Site Reliability Engineering (SRE) team. The SRE team focuses on developing and maintaining Wikimedia’s product infrastructure. As this work would need to be taken on by the SRE team, and we do not control or manage their backlog and set of priorities, it is not appropriate as a wishlist item.

Third, this wish has multiple workarounds already available (which we will explain below). While we understand that the voters of the wish hoped to find a new, robust article reminder system, we found that a range of tools are already available to users. When we weighed all of the technical difficulties, risks, and dependencies against the current options and workarounds available to users, we decided that the most prudent choice would be to decline this wish.

Workarounds: There are quite a few workarounds for this wish. First, there are some user scripts that allow for article reminders or ways to keep tabs on articles. These include Customwatchlist (created by MusikAnimal), RemindMe (created by DannyS712), and Notizen.js (created by Schnark), among others. Second, users can use their sandbox as a personal space to record notes and keep track of important things (although it is public). Third, users can set their own personal calendars, which can be privately managed, through a separate service, such as Google Calendar, Thunderbird, etc. Fourth, if you are interested in watching a page temporarily (which has some parallels to a reminder system), the Community Tech team has begun the process of releasing the Watchlist Expiry feature. You can check out the release schedule to see when it will be available on your wikis.

Conclusion & next steps: We thank everyone who voted on this wish. Although the project is much too large for our team, we do think it is an exciting wish, and perhaps it can be something that is pursued in the future.

2FA for all concerned editors edit

After analyzing this wish as a team, we have decided to decline this proposal. Below, we have explained our rationale for this decision. We have also provided potential next steps for people who are interested in seeing wider support for 2FA in the future.

Rationale: This wish proposed that we add 2-factor authentication (2FA) for all concerned editors. Currently, 2FA is only available for a small group of editors that have advanced permissions. With this change, all editors would be able to add another layer of security to their accounts. We understand that security is important to people, so we wanted to see if it was possible to fulfill this wish.

When we analyzed this wish, we identified some serious issues. First, we don’t have the personnel and basic infrastructure to support the wish. The actual coding to enable 2FA for all editors is minimal; we could do that. However, if we made this change, we would need support systems in place, in case people got locked out of their accounts. For many companies, they solve this issue by having paid staff to act as support representatives, who may confirm the identity of a user and then unlock their accounts. Unfortunately, the Wikimedia Foundation does not have the resources of such a staff, and the Community Tech team does not have the power to make such staffing decisions. For this reason, we would need to create an automated solution to handle issues like users being locked out of their accounts.

Second, if we chose an automated solution, this would be a Security team ticket. The main issue with an automated solution is figuring out how to prevent abuse and finding the right workflow for safely restoring the tokens. This would be a large project with various use cases and complexities to address, and it would be beyond the scope and domain of the Community Tech team. It would need to be a Security team project instead. The Security team has their own backlog and sense of priorities, which we do not dictate. While they may pursue such work in the future, it is not something that we can take on as a community wish.

Workarounds: While we cannot satisfy this wish, there are some steps that you can take to improve the security of your account. It is always recommended to choose a password that is unique (i.e, not used on any other platforms or sites), long (i.e., at least 10 characters), a mix of numbers, symbols, and a mix of lower/uppercase letters. It is also recommended that you occasionally reset your password. Some people choose to use password managers, which can help with setting and maintaining strong passwords. You can refer to this guide from English Wikipedia for more recommendations.

Conclusion & next steps: Overall, this wish would need to be handled by the Security team. So far, Security folks have shared in T166622 that some steps would need to be taken before any such work could continue. We recommend that interested parties consult T166622 for relevant updates. In the meantime, users can work to ensure that they have strong passwords (see tips above in “workarounds”). We thank everyone who participated in this wish proposal.

Eligible for 2021 Community Wishlist Survey edit

Below, we have shared two wishes that can be re-proposed in the 2021 Community Wishlist Survey. This means that we have conducted analyses on both wishes, and we have concluded that they are feasible for the team. For the first wish (section name in diff), no changes need to be made to the wish (unless people want it changed, of course). For the second wish (named references in VE), our analysis has identified potential issues and risks, but we believe we have come up with a solution that would make the project manageable for the team. For this reason, we would love to hear feedback on the proposal.

Section Name in Diff edit

Result: After completing both a technical and product analysis, we are excited to share that this wish can be included in the 2021 wishlist survey. No changes to the wish are needed. This means that everyone can vote on this wish again, in order to determine its priority against all other wishes. After voting is complete, we will assess the priority of this wish and see what further steps are appropriate for the wish. We may choose to work on this wish, if it remains high priority after votes are tallied, or we may keep it in the backlog but not pursue it in the immediate future, if it receives minimal votes.

Next steps: Please participate in the upcoming survey and let us know what you think of this wish. If you think it should be voted on again, you can re-propose it in the 2021 survey.

Named References in VE edit

  • Wish page
  • Project page
  • STATUS: Accepted in 2021 survey for vote, if proposal (as detailed below) accepted.

After analyzing this wish as a team, we have decided to propose a specific solution. If people find this solution appropriate, we’ll be able to accept the modified version of this wish in the 2021 wishlist.

Proposal: This wish proposes that a new naming system is created for references in VisualEditor, which currently assigns reference names that are meaningless to most users (such as ":0" and ":1"). Our proposal is that, rather than such references only including a number and colon (such as “0:”), we provide an improvement to the existing format. For citations with websites, we would include the domain name and a number. For example, a reference from the Guardian website (www.guardian.com), may be “guardian-0” or “guardian-1.” For citations that do not have a website, we could potentially also include some automatically generated names based on the author or book title, such as “adamslaura-0.”

Why this approach?: After conducting a technical investigation to look into this wish, we consulted the Editing team to discuss our findings and potential next steps. Our first question was whether we should allow names to be generated automatically (as in the current system) or if users could manually enter names into VE. From our research, we determined that a manual system, which was not yet in place, would be much too big and complex of a feature for us to build. Simply put, it was not within scope for our team. Furthermore, there was a strong user experience and product argument to keep the automatic generation. Many people like that they can easily add in VE. We didn’t want to complicate that process by adding extra steps. So, first of all, we decided that a name should be automatically generated.

Second, we discussed how the name should be automatically generated. If we chose a totally new format that did not build upon the numerical scheme, this work would be out of scope for the team. This is because we would need to work with template data, which is complex and has many edge cases. However, when we began discussing stripped-down alternatives, we began to think of how we could build upon the existing format. It was from these discussions that the option to add the domain name to the number came about. We liked this idea for two reasons. First, it was technically feasible. Second, it would solve the problem of VE currently providing citation names that are meaningless. The addition of a relevant name (such as the domain or author) would add meaning.

Question: What do you think of this approach? Would you be interested in updating the wish proposal to accept this solution? If so, we would be happy to accept it for voting in the 2021 wishlist survey. However, if the wish remains broader (either a manually entered reference name or an automatically generated name that requires us to work with template data), we unfortunately would have to rule it out as out of scope. We look forward to hearing to reading your feedback!

Final notes edit

Thank you to everyone who participated in the 2019 Community Wishlist survey. We're so happy that we could release new features and improve existing features. We all learned so much from the range of volunteers who participated in the 2019 wishlist process (either as proposers or voters), shared feedback on the wish and project talk pages, and collaborated with us to deliver meaningful solutions. As for the 4 wishes we needed to decline, we only did so after careful consideration and analysis. We hope that the workarounds we shared provide some alternatives and that opportunities arise for other teams or volunteer developers to continue to work on those problem areas. We're also excited about the new wishlist format, which aims to prevent many of the issues that resulted in the 4 declines in the future.

As for next steps, we'll be launching the 2021 Community Wishlist Survey soon, which will begin on November 16th. You can expect an update very soon with official guidelines and calendar dates. As written above, the section name in diff wish can be re-proposed (unchanged), as well as the named references in VE wish (if the proposal we shared is accepted). You can also submit new wishes or other old ones, if we haven't previously declined them. Again, thank you, and please feel free to share your feedback on the talk page. We're so excited to read the proposals in the 2021 Community Wishlist Survey!

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Status_report_1&oldid=24729114"