Community Tech

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Translate this page
Other languages:

Community Tech is the Wikimedia Foundation team running the Community Wishlist Survey. It builds and improves curation and moderation tools for experienced users, supports bot operators, and more. The creation of the team is a direct outcome of requests from the most active contributors. The team works closely with editors, volunteer developers, and other Wikimedia teams.

Current selected projects[edit]

To complete as many wishes as possible, Community Tech attends to the voted wishes with a prioritisation framework in mind. The framework guides how we come about the current selected projects.

Projects Project status
Real Time Preview for Wikitext
Complete from the Noun Project (3557299).png  Done
Generate Audio for IPA
Gear from the Noun Project (2345699).png  In development
Audio links that play on click
Gear from the Noun Project (2345699).png  In development
Better diff handling of paragraph splits
Gear from the Noun Project (2345699).png  In development
Autosuggest linking Wikidata item after creating an article
Gear from the Noun Project (2345699).png  In development
Gadget: Who is active
Complete from the Noun Project (3557299).png  Done
Enable negation for tag filters
Complete from the Noun Project (3557299).png  Done
Enable Thanks Button by default in Watchlists and Recent Changes
Complete from the Noun Project (3557299).png  Done
Enable live preview by default
Complete from the Noun Project (3557299).png  Done

Team Mission[edit]

We surface the movement's technical platform needs and build and support needed tools with engaged contributors.

Values[edit]

  • KNOWLEDGE: The fact of knowing about something; general understanding or familiarity with a subject, place, situation etc.
  • KINDNESS: Having a benevolent, courteous, friendly, generous, gentle, liberal, sympathetic, or warm-hearted nature or disposition, marked by consideration for – and service to – others.
  • COLLABORATION: To work together with others to achieve a common goal.

Updates[edit]

Main article: Community Wishlist Survey/Updates

March 13, 2023: Better diff handling of paragraph splits update[edit]

The team has continued work on this wish on both the engineering and design side and we wanted to share the updates with you.

Editing mode.png
Legends tooltips inline.png
New paragraph.png
Delete paragraph.png

Thank you to all of you who took the time to engage with us and provide feedback on the talk page. We read through all of the feedback and did an aggregate analysis on the points made. We then combined your feedback on those proposed designs, as well as unmoderated user research, and we've finalized the proposed designs to go into engineering for the improvements regarding the wish changes.

Please see the designs in this update which include:

  • Switching between diff modes via dropdown
  • Improving the accessibility of inline diffs with legends and tooltips for desktop
  • Improving the display of a change that introduced a new line or paragraph
  • Improving the display of a change that deleted an existing line or paragraph

In addition, a demo of the changes for the underlying comparison engine has been created.

Before you try out the demo to give us feedback, please note:

  • It's a work in progress, our QA engineers are currently using a list of comprehensive diffs to make sure the changes are consistent with the current version of the two-column diff experience or an improvement on the UI.
  • The demo page does NOT include all final UI changes but can give testers a good sense of how the completed two-column diff experience will end up looking.
  • To use the demo, paste the same text into the two boxes and modify the text in the right box. The diff under it will show what changed.

We'd love to hear your feedback on our talk page!

Next Steps[edit]

  • Accessibility of Design Colors: Our designer is working closely with our Design Systems team to determine the accessibility of the designs. We anticipate having to change the shade of them to a slight degree to make it more accessible but the colors will remain similar to the blue and yellow currently displayed on two-column and inline diffs.
  • Release plan: We are working out a release plan and a timeline of next steps and will be including this in our next project updates! Releasing changes to the underlying engine on the diff follows a different process than traditional releases in Mediawiki software so we will be sure to update you with steps and details next time.

We also want to include big thank you in this update to a non-Community Tech staff member, Tim Starling, who graciously stepped up to help us with the underlying changes in the C++ engine of wikidiff2. We are always happy to receive support fulfilling wishes from other members at the Foundation that have the expertise necessary to fulfill a wish even if they are not in the Community Tech team.

We're looking forward to hearing from all of you!

Open Questions from first update: We want to hear from you![edit]

  • Are you interested in conducing user research on the new proposed interface to diff paragraph splits? If so, will you please post that you're interested in the Talk Page?
  • What other pain points manifest themselves when you view the diff?
  • How might we address the root pain points that address the confusion around paragraph splits?
  • How does the use of color indicate which content is added, removed, or stayed the same?


March 7, 2023: Community Wishlist Survey 2023 results published[edit]

The Community Wishlist Survey 2023 edition has been concluded. We have published the results of the survey and will provide an update on what is next in April 2023.

December 20, 2022: Wishathon Update[edit]

This year, the Community Tech started a tradition of hosting an internal WMF Wishathon. During this Wishathon, our team cancels meetings for an entire week and spends the entirety of our time working on "smaller" wishes outside of our regular "larger" wish workload. For example, the Better diff for paragraph split wish is a complex large wish that requires heavy planning with regards to design research, technical architecture as well as plans for quality assurance and dependencies with the Performance team. These wishes usually take months for us to grant. The Wishathon inspires us to grant wishes that are more straight forward and require less cross-team dependencies and planning. While these may not be the most popular wishes, we still believe they are impactful and heavily desired by the participants who voted on them.

This past December, we extended an invite of participation to other engineers, designers, and managers in different teams to join us for a week long Wishathon and help us make progress on the work required to grant these smaller wishes. Thanks to the additional participation from engineers on other teams, we were able to finish four wishes and refactor an important piece of code. Please note that in the spirit of moving quickly and building wishes people need, we did not conduct the full cycle of research and communication outreach that we usually complete on larger wishes. You can read about the wishes we completed last week, their impact, and their scheduled releases below.

Wish: Autosuggest linking Wikidata item after creating an article[edit]

This wish received 92 support votes and ranked as the #12 most popular wish in the list of the 2022 wishes.

Problem: Someone creates an article in Language A Wikipedia, but they do not know there is already the same article in Language B Wikipedia (often a smaller language version), so no Wikidata linkage is made. Proposer has seen many cases between Chinese Wikipedia (zh) and Cantonese Wikipedia (yue).

Work was completed and will be available as a gadget the week of January 16, 2023.

Impact of wish

  • More Wikipedia (and other project) pages linked to corresponding Wikidata items
  • Greater awareness of Wikidata for wiki contributors
  • Better maintenance of links between Wikipedia languages, and other Wikidata benefits

Wish: Enable negation for tag filters[edit]

This wish received 41 support votes and ranked as the #27 most popular wish in the list of the 2022 wishes.

Problem: When view feeds such as Special:Contributions or Special:RecentChanges we can currently filter by tags, but not by the negation of tags.

Work was completed and will be out in the set of deployments occurring the week of January 3, 2023.

  • Original Wish
  • Relevant Tickets and Patches
    • ✅ Closed T119,072: Allow Tag negation on Special:Contribution
    • ✅ Closed T174,349: Allow Tag negation on Recent Changes
    • ✅ Merged Patch 866,814: UX for Tag negation on Special:Contribution
    • ✅ Merged Patch 867,726: fixed testing for forms to work better with hide-if (to allow next)
    • ✅ Merged Patch 866,817: UX for Tag negation on Special:Log (out of scope, but easy)
    • ✅ Merged Patch 867,255: Expose Tag negation in API and feed (to allow next)
    • ✅ Merged patch 867,731: Prevent tagfilter param from being set to 'all' (to allow next)
    • ✅ Merged Patch 867,224: UX for Tag negation on Recent Changes / Watchlist
  • Status:
    • 866,814 already in prod (i.e. on Special:Contributions)
    • 6 patches merged, two tasks closed, one wish fulfilled
  • Next steps:
    • Deploy to prod for Recent Changes and Special:Log with next train
  • 🏆 Special thanks to Team Members: Roan Kattouw, Denny Vrandecic, James Forrester, Moriel Schottlender

Honorable mention to Matěj Suchánek, a volunteer who laid the groundwork for this by writing this patch in 2020.

Impact of wish

Users will be able to filter out edits based on a tag on Recent Changes, Watchlist, Special:Contributions, and Special:Log.

Wish: Enable Thanks Button by default in Watchlists and Recent Changes[edit]

This wish received 62 support votes and ranked as the #33 most popular wish in the list of the 2022 wishes.

Problem: The Thanks button is only available on individual Page Histories, which very few people interact with on a regular basis -- especially more experienced editors. The number of newbies looking at individual history pages, is miniscule.

  • Original Wish
  • Relevant Tickets and Patches
  • 🏆 Special thanks to Team Members: Jon Robson
  • Status: The work has been merged and is available for testing in Beta, and will be deployed to users with the first train of 2023 which is scheduled for the week of Jan 3.

Impact of wish

Users will now be able to thank other users from inside Watchlists and Recent Changes pages.

Wish: The "tag name" on the change line should link directly to "tagged changes"[edit]

This wish received 18 support votes and ranked as the #162 most popular wish in the list of the 2022 wishes.

Problem: The tag on the change line currently looks like this: 

   14:33 John Callahan's Quads!‎ (diff | hist) .. (−12) .. Rng0286 (talk | contribs) (lorem ipsum) (Tags: Visual edit, Mobile web edit)

The tag name is either a link to a help page or just plain text. It is not easy to find edits with the same tag.

Impact of wish

Users will now be able to click on the tag name to find edits with the same tags within change lines.

Refactoring code from the Page Triage codebase for easier collaboration[edit]

Impact of work

Modernizing the codebase to help make bug fixing and feature development easier

What's Next?[edit]

In addition to the wishes granted above, we were able to make some progress on a handful of other wishes. Community Tech will be assessing which wishes we can finish based on the progress left on them. We are excited to continue this Wishathon tradition and welcome your feedback in the talk page of this update! Thank you for participating in the Wishlist, we hope to see you in the upcoming annual survey opening January 23, 2023.

December 16, 2022: Realtime Preview is coming out of beta[edit]

The Realtime Preview for Wikitext is coming out of beta as an enabled feature for every user of the 2010 Wikitext editor in the week of January 9, 2023. It will be available to use via the toolbar in the 2010 Wikitext editor. The feature was the 4th most popular wish of the Community Wishlist Survey 2021.

December 5, 2022: The 2023 Community Wishlist Survey will happen in January[edit]

Do you have an idea for a tool or platform improvement for Wikimedia projects? This announcement is for you!

The Community Wishlist Survey (CWS) 2023, which allows contributors to propose and vote for tools and improvements, starts next month on Monday, 23 January 2023, at 18:00 UTC and will continue annually.

We are inviting you to share your ideas for technical improvements to our tools and platforms. Long experience in editing or technical skills is not required. If you have ever used our software and thought of an idea to improve it, this is the place to come share those ideas!

The dates for the phases of the survey will be as follows:

  • Phase 1: Submit, discuss, and revise proposals: Monday, 23 January 2023, to Monday, 6 February 2023
  • Phase 2: WMF/Community Tech reviews and organises proposals: Monday, 30 January 2023 to Friday, 10 February 2023
  • Phase 3: Vote on proposals: Friday, 10 February 2023 to Friday, 24 February 2023
  • Phase 4: Results posted: Tuesday, 28 February 2023

If you want to start writing out your ideas ahead of the Survey, you can start thinking about your proposals and draft them in the CWS sandbox.

We are grateful to all who participated last year. See you in January 2023!

December 1, 2022: Better diffs usability testing[edit]

We have been working on different design alternatives for Better diff handling for paragraph splits, the #1 wish in the Community Wishlist Survey 2022! We have invited the community to sign up for usability tests and give feedback.

May 3, 2022: Real Time Preview launching to partner projects[edit]

We have launched a version of the Realtime preview feature to Polish Wikipedia. Its community has agreed to partner with us and give us feedback on how to improve it before we launch to the rest of the users. Please find our complete Release Plan. Read more

February 15, 2022: CWS 2022 results[edit]

The Community Wishlist Survey 2022 is over! We would like to thank everyone who participated in this year's edition and express our special gratitude to those who made outstanding contributions to the survey below the results. We could not have done it without all of you!

Curious about what happens next? Learn about our prioritization process and check out the ranking of prioritized proposals for this year. Read more

November 8, 2021: Warn when linking to disambiguation pages[edit]

We have an update about the wish. We have finished user tests. Read more

What we do[edit]

We mainly work on the Community Wishlist Survey. It's an annual project which contributors from all Wikimedia wikis can ask for changes that they would most like to see.

We work on relatively small tasks and that have a direct benefit for the most active contributors. In particular, we support those who:

  • Participate in the curatorial and administrative layers of the Wikimedia projects
  • Work on technical features for wikis such as templates, modules, gadgets, user scripts, and bots.

Occasionally, we also work on other projects. We do that to help smaller groups that may not have enough support in the Survey. This is how we have worked on:

We also periodically take part in a "wishathon".

Scope[edit]

Tasks that are in scope include:

  • Creating gadgets, bots, and wizards to help users in what they already do
  • Modifying existing gadgets and bots so that they can work on more projects
  • Converting heavily-used community code (gadgets and user-scripts) into part of the MediaWiki software
  • Building tools for WikiProjects
  • Identifying and fixing issues with most important old tools for experienced users, such as AbuseFilter or Citation bot
  • Creating better documentation for these tools so that they can be better utilized

Tasks that are not in scope include:

  • Maintaining orphaned/abandoned projects from other WMF teams.
  • Supporting internal needs of WMF teams.
  • Large, long-term development projects like converting Commons to use structured meta-data or creating an entirely new watchlist interface.
  • Being the point of contact for all community technical requests.
  • Sysadmin type tasks such as managing Toolforge, improving site performance, creating new wikis, managing IRC channels, etc.

For a more detailed breakdown of the team's current work, check our Kanban board in Phabricator.

Team[edit]


Collaboration[edit]

The Community Tech team has a similar mandate to Wikimedia Deutschland's Community Tech team – Technischer Communitybedarf, or TCB – which provides technical assistance and software development for the German Wikimedia community. We will be collaborating with them on projects that overlap between our teams and assisting each other with technical assessment and code review. We will also be collaborating with other WMF development teams when high-priority community requests fall within their scope. In such cases, we will work with the leaders of the other teams to negotiate timelines, expectations, priorities, and ownership. We also spend a good deal of our time working with and supporting Wikimedia volunteer developers.

We uphold the civility standards set by the Terms of Use. We observe and maintain the code of conduct for Wikimedia technical spaces in our interactions, and ask that all contributors to Community Tech spaces do the same.

How can other teams contact us?[edit]

Feel free to contact any of us individually, on IRC at #wikimedia-commtechconnect or through the #talk-to-commtech channel on Slack.

Engaging with Community Tech[edit]

We triage and track our work in Phabricator. Outside the annual Community Wishlist Survey, use the following Phabricator templates to log feature requests and bugs for the tools we maintain:

We review and triage new requests on a biweekly cadence.

Guidelines[edit]

It's important to us...

  • To work on projects that have a big impact
  • To help large wikis and small wikis, in many languages
  • To be open and communicative
  • To be responsive to people's requests and concerns
  • To be calm and civil, and to assume good faith

We're a small team, and there's a lot to do! We want to be as helpful and effective as we can, so we can't take everything on. Saying no to requests that we can't help with is an important part of our job, because it frees up time and energy for the requests that we can help with.

But "no" is hard to hear sometimes, so here are some guidelines about working and communicating with the Community Tech team.

  • Please be calm and civil, and assume good faith on our part. We care about the projects too.
  • We love our jobs and we work hard, but we don't work 24/7, and we can't guarantee an immediate response.
  • If a specific person or issue is taking an outsized percentage of our on-wiki time, that takes time and attention away from other people. We'll sometimes have to close a conversation, and say that we can't spend more time on a particular subject.
  • We can't take on projects that are currently on another product team's roadmap, or a project that directly conflicts with another team's work.
  • If there's an issue with another product team's work, we can direct you to the appropriate person to talk to.
  • We can't answer questions about staffing issues, or confidential matters.

Our process for defining our Values and Mission[edit]

In a collaborative session we all came together as a team to work towards being able to formulate our mission statement. To get there we first tried to think about which values we most care about individually to then see where they overlap, because we wanted to make sure that they are truly with us as a group of humans.

Three values stood out to us, which are: Knowledge, Kindness and Collaboration

Values statements itself are pretty broad and can be interpreted differently so we discussed them thoroughly to understand what behaviours they actually translate to, we’ll summarise here quickly what we mentioned:

Why do we care about Knowledge?[edit]

We do not want to be protective of our knowledge. If we discover something or implement something new we would like to write about it, let others know compassionately. If we make a decision, document it and explain the reasons. This is especially important because we want to be welcoming people to join the movement as new contributors or team mates.

Why do we care about Kindness?[edit]

We are conscious that we can never know what struggles others might be facing, always remember that we may not be aware of the whole picture. By being considerate and courteous to one another we ensure that we all feel included and encouraged to work more openly with one another. In addition to that being kind can mean being clear about if and how we can help or resolve a problem.

Why do we care about Collaboration?[edit]

Collaboration is the backbone to what we do and fosters innovation by combining ideas from different viewpoints. When giving explanations we want to be detailed and link to more info wherever possible, to make sure our explanations are meaningful to others. We welcome and actively seek ideas & feedback and questions from each other, WMF, and the community.

Mission statement[edit]

Having our values and beliefs in mind we further thought about what our mission statement might be. What are our responsibilities towards the movement, the community and towards each other and what connects us to the CommTech team. Are we just building some tools or is there any greater duty that motivates our work? This one summarised our opinions best:

We surface the movement's technical platform needs and build and support needed tools with engaged contributors.

As we want to contribute to the increase of the movement’s inclusiveness and growth, we surface the needs of the contributors, as long a they are of technical nature. Some of the tools we build ourselves, while we communicate others to the foundation to increase awareness of these needs across different teams.

Strategy[edit]

One of the challenges our team faces is that we touch many different codebases and existing tools, that we don’t know well, therefore we currently have two main initiatives:

Collaboration Initiative[edit]

The need to collaborate and work closely with others at higher frequency than other teams is quite evident as we frequently build on top of other team’s work. If we touch existing codebases we need to make sure our tools are implemented in a way that matches their way to work and works towards the same goals.

The goal of this initiative is to improve knowledge sharing and collaboration across teams and within teams and find ways to check in with other devs before implementing work to make sure we do not build things from scratch that have previously been implemented. In addition to that we know we can build more innovative solutions by allowing for more collaboration. We thought of ways to encourage for more cross team collaboration for engineers i.e. by encouranging temporary exchange for engineers across teams, by reserving weekly internal collaborative programming sessions that engineers from other teams can visit and add to the agenda of these sessions.

Every quarter, since April 2022, we have an internal hackathon where we work on a series of proposals from this years wishlist and invite other teams to join us for a week. Often times specialists for certain fields are already existent in other teams and working on different projects for a week can increase the sense of belonging within the engineering team as a whole and have a positive impact on levels of collaboration in the future.

Maintenance Initiative[edit]

With a growing list of projects we maintain, we are left more and more distracted from our priorities.

We do want to provide maintenance for our work, but want more structure for how we provide it. This year we reviewed our approach to maintenainenance and restructured our strategy towards maintenance. Here are the outcomes of this discussion here.

We internally decided how to make these changes happen and are tracked our decision making progress.

Documentation Initiative[edit]

Main article: Community Tech/Documentation

With the intention to understand the work of other teams we often look at codebases that are new to us. A good level of user and developer documentation is absolutely essential to get an understanding of the implementation details, goals and challenges of other's work. As a team we want to be exemplary in producing really good documentation, ideally documenting first before implementing and frequently updating others about the status of our work. To achieve that we are currently looking studying how other teams document their work to make sure we find a way that is aligned with other teams. We want to keep documentation close to our code.

When organising collaborative programming sessions we collected recommendations and wrote it down in a guide.

After researching different approaches for how to advance the way we document our work we have come accross documentation-driven development, which seems to meet our needs in respect to how we value docs. We are experimenting with this approach with our current wish Better diff and already enjoyed it's benefits as we are more aligned on what we are working towards and can get feedback from users before implementation.

Users Guide[edit]

Template for Reference

  • Preferred Name:
  • How to talk to me:
  • (Optional) Pronouns:
  • (Optional) Things I like:
  • (Optional) Things I’m bad at:
  • (Optional) Annoying things I do:
  • (Optional) How to cheer me up when I am grumpy:
  • (Optional) Hot takes:
  • (Optional) Anything else you should know about me:

Find our user guides here:

User guides from former team members[edit]

Further information[edit]

Subpages list

Pages with the prefix 'Community Tech' in the 'default' and 'Talk' namespaces:

Talk:

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Tech&oldid=24734476"