Community Tech

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

The Community Tech is a 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 projects[edit]

Projects Project status
Copy and paste from diffs
Complete from the Noun Project (3557299).png  Done
(Un)delete associated talk page
Gear from the Noun Project (2345699).png  In development
Warn when linking to disambiguation pages
Complete from the Noun Project (3557299).png  Done
Real Time Preview for Wikitext
Gear from the Noun Project (2345699).png  In development
Bibliographic bot for Wikidata
Declined

See also: Community Wishlist Survey 2021 · 2021 results

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

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

November 2, 2021: Real Time Preview for Wikitext[edit]

Thank you for your comments on the talk page, as well as the latest "Talk to Us" video call. Also, we have conducted usability testing. We are sharing the most important findings. Read more


October 19, 2021: Declining the Bibliographic Bot Wish[edit]

Wish Title: Bibliographic Bot

Phabricator Ticket for Investigation

Wish Rank: #14

Reason Summary: Scope of work too large, not enough votes.

We have decided to decline this project. We did this after careful consideration and multiple rounds of feedback within the team and conversations with other teams at WMF and affiliates.

Rationale: First, the engineers and designers investigated the scope of work defined in the problem statement of the wish (T243150). We have determined that the work alone far exceeds our initial estimation of it.

This wish scored very high in our prioritization process because at a glance, it seemed straightforward to duplicate the Citoid behavior inside of Wikidata. We assumed that it involved a low complexity from a technical and design perspective because we could reuse the code and designs. However, citations in Wikidata must be linked as references to other objects in the database. This significantly increases the complexity.

This wish did not score the top 10 most popular wishes. It came in at #14. We were wrong about the initial estimation. In fact the work for this wish was worked on by Wikidata/Wikimedia Deutschland for multiple months. The final solution was too complex to complete given the resources available at the time. This would take the Community Tech team multiple months to complete, and there are other wishes that were more popular that we will work on instead.

August 20, 2021: The 2022 Community Wishlist Survey will happen in January

We will be running the Community Wishlist Survey 2022 in January 2022. We need more time to work on the 2021 wishes. We also need time to prepare some changes to the Wishlist 2022. In the meantime, you can use a dedicated sandbox to leave early ideas for the 2022 wishes. 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:

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.

We uphold the civility standards set by the Terms of Use. We observe and maintain the friendly space expectations for Grants spaces in our interactions. We ask that all contributors to Community Tech spaces do the same.

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.

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.

We also host monthly Talk to Us hours.

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.

Our Initiatives[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 to understand other team’s work, if we touch existing codebases, and to make sure our tools are implemented in a way that matches their way to work.

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 don’t 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 collaborative programming sessions. We thought of ways to encourage for more cross team collaboration for engineers i.e. by allowing 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.

In April 2022 we are planning to 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 and have a positive impact on collaboration in the future.

Documentation Initiative[edit]

With the intention to understand the work of other teams we often look at codebases that are new to us. A good 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 writing 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.

As it seems currently documentation lives separate from the code in Mediawiki.org and gets there manually. Because one of our team values is “knowledge” we want to provide outstanding documentation, as we appreciate other teams sharing their knowledge i.e. implementation details of tools they build, setup guides, usage example. To achieve this goal there are the following steps we want to take: we want to value code contributions as much as documentation, we want to keep documentation in the same repository as code and make documentation requirement for release and have a consistent contribution process for code and documentation, to make sure documenting your work is easy and is done just while we write code.

More details: Community Tech/Documentation

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:


Further information[edit]

Subpages list

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

Talk:

Wikimedia Foundation departments
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Tech&oldid=23035525"