Community Tech/Definition draft

Some thoughts on defining what the Community Tech team is, and how this team works.

Community stakeholders

The core difference between Community Tech and other teams is that Community Tech serves the existing active contributors. While (for example) the Reading team is reaching out to new readers, and creating new reading experiences on mobile and desktop, Community Tech's customers are the people who are currently active on the wikis.

Our core stakeholders are the existing contributors, and our work is an ongoing collaboration with those stakeholders. Tools and features that we work on should be primarily used by volunteers -- contributors, program leaders, admins, chapters, etc.

Our stakeholders include all Wikimedia wikis and languages. English Wikipedia is Wikimedia's largest wiki, but it's not the only one, and many smaller projects and languages also have technical needs that we can help with. Whenever possible, the team should work on internationalizing features, to benefit as many languages as possible.

Choosing and prioritizing projects

The projects that Community Tech works on come from direct requests from communities and volunteers. The annual, international Community Wishlist Survey should always be the core of our work.

Not everything needs to be decided by majority vote; we don't want to leave smaller communities consistently shut out of the process. Still, we should always be able to connect with a group of stakeholders who actively want the project that we're working on.

Specific, iterative change

There are a lot of potential projects that Community Tech could work on, so we focus on specific problems that we can solve, and then move on. Every project should have a clear definition of done.

Resisting the howabouts: We work on some of the core contributor tools that haven't changed much over the years -- watchlists, diffs, categories -- and there's always a temptation to say, "while we're doing that, how about we also..." We need to resist that temptation, and limit the scope, just making the changes necessary to achieve our goal. If there are related projects that would be worthwhile, they should be split off, and prioritized in collaboration with the stakeholders.

Collaboration

Community Tech likes working with other people, because other people are smart, and they help us save time. If there are volunteers, teams or chapters that are currently working on a problem, we should support their work, rather than taking it over or duplicating it.

Community Tech does work that's too big or complicated for volunteers to do. We should work with the Technical Collaboration team to develop an active backlog of projects that are possible/appropriate for volunteers, which could be used for Hackathons, GSoC, and other volunteer development.

Our Tool Labs project is building a system that will better support volunteer devs. We encourage people to share code, and make it easier for other people to fix and maintain tools. Tools and bots that the community thinks of as an important public utility should not have a single point of failure. Community Tech, Technical Collaboration and Tool Labs encourage community/volunteer ownership of these tools, to share the maintenance burden and help orphaned tools.

Transparent, collaborative development

Community Tech's work should be as transparent as possible, publishing our notes and plans, and gathering feedback from stakeholders throughout the process. We're not doing this to cover our ass or rubber-stamp our decisions; we're genuinely interested in what other people have to say.

When we're building something new, we publish early wireframes and ask for feedback. Then we publish new wireframes, responding to that feedback. We don't just say "thanks for your feedback" and then move on to the next step, ignoring what people have said.

That doesn't mean that every single piece of feedback can change the scope and direction of a project. Any specific individual can have a bad idea, or misunderstand the goal, or just disagree on the best approach. But if we hear the same thing from a number of different stakeholders, that means there's something important there, and we need to pay attention and respond. We're smart and we have strong product development experience, but we don't know better than the people who are going to use the products that we build.