Page MenuHomePhabricator

Maximize volunteer/staff engineer engagement in MediaWiki software projects
Closed, InvalidPublic


It would be useful to define how MediaWiki software projects are supposed to work. The Team Practices team is working on a similar route, and we have a Project management page in, but we could welcome more advice especially in the area of collaboration with volunteers and handling community collaboration in general.

Good practices

(These are just quick notes made a while ago; everything is open to discussion and edits.)

  • Common understanding
    • We are a community with a foundation, not a foundation with a community.
  • All documentation in - including value proposition and user documentation.
    • Easier to maintain, promote and watch.
    • OSS development context clear. Links to/from Bugzilla etc are natural.
    • Simplified, adapted intros can be created in Wikimedia projects when deployment comes.
  • Calls for feedback point to a central point in
    • Criticism happens next to the core docs and it's easier to integrate.
    • Less risk of Wikipedia-centrism. Neutral field for all Wikimedia projects and 3rd parties.
    • Less risk of duplicated discussions in different places.

Event Timeline

Qgil raised the priority of this task from to Low.
Qgil updated the task description. (Show Details)
Qgil added a project: Developer-Advocacy.
Qgil added a subscriber: Qgil.

I think the current push of VisualEditor to full deployment will give us a good excuse to define and document best practices of open development and community collaboration.

Common principles of prioritization are good to avoid unproductive fights. is the starting point, and now suggests a more fine-grained level of detail that might be worth looking at.

This sounds like a valuable (and possibly incredibly ambitious) project. Can you flesh out a bit more how broad (or narrow) you envision the document? Is the intent just to focus on open/community development, or on development more generally? Would it be more at a conceptual level, or at a practices level, or at a tool/HOWTO level (or more than one of those)?

I have just pasted in the description some notes I had in a sandbox.

This idea started in one of those periods of conflict, and my attempt was/is to at least analyze why conflict happens and how to prevent it with better processes and attitudes. While I agree that writing the definitive cookbook is to ambitious as a goal, I think we could put together a document that would outline some DOs and DON'Ts and would link to interesting related resources.

Every time a new conflict appears, we could go back to this document looking for guidance or aiming to update it in order to integrate the new lessons learned. Over time, this document should help users, developers, and just any contributors working better together.

Qgil removed Qgil as the assignee of this task.Apr 16 2015, 10:10 AM

When I proposed this task (on-wiki, before Phabricator) there was no Team Practices group, no health check survey, etc. I keep being busy with other things that probably nobody else will work on. I think it is time to let this task go and offer my help to whoever wants to drive it.

Joel, thank you for taking this task! Let me know if you need any help.

Notes from discussion between Joel and Quim:

Several different models for staff/community relationships:

  1. Customer/vendor model. If staff does not communicate regularly and well with community while developing software and sites, the resulting work may not serve community's needs

1a) may build the wrong thing because the staff didn't hear the community
1b) may build the wrong thing because the staff didn't lead the community to best place as a customer
1c) may build the right thing and still not get community acceptance because of the process. "right thing" is thus not just code, but a larger process.

example metrics: quality of product, acceptance of product, success of product

  1. Staff/volunteer model: Staff may be more productive by enabling community technical participation, or, the community may meet its development needs better with a paid staff working together with many volunteers compared to a paid staff working in isolation.

example metrics: same as 1.

2a) Including community participants at a technical level (code, bugs, patches, etc) is itself a value of the community, which worst-case may produce contradicting values of efficiency vs inclusiveness.

example metrics: age of submitted patches. % of technical work done by volunteers.

2b) Sustaining a volunteer community in addition to paid staff may server other long-term goals such as succession planning.

example metrics: size of community; trends in size of community; rate of hire from community into Foundation; % of Foundation hires that come from community; diversity of community.

Next steps:
Nothing specific yet. Joel to keep this in mind while continuing process review of VE, and Joel and Neil may want to interview Quim as part of stakeholder discovery and exploration. Quim has a presentation it may assume a consensus on goals and practices that should be tested before taken as given.

JAufrecht renamed this task from Way of working in a good MediaWiki software project to Maximize volunteer/staff engineer engagement in MediaWiki software projects.May 14 2015, 9:46 PM
JAufrecht removed JAufrecht as the assignee of this task.

When you say Volunteers do you mean all groups, developers only, editing communities?...

I think the focus here is developers; happy to take better terminology.

Common principles of prioritization are good to avoid unproductive fights. is the starting point

T103556#1458377 is highly related (as priority is a mix of "urgency" and "impact" plus project maintainers have different priorities than parties like "the community").

Is this really about "engagement in MediaWiki software" or "Interaction with each other"? The first indicates that you want more devs to write more software (even if they all do so as lone wolves); the second indicates that you want devs to talk to each other more (regardless of the effect on lines of code written, etc.).

Removing Team Practices Group for now; a number of TPGers are subscribed and following the conversation closely. If you need something specific from the TPG, we suggest you consider using a template along the lines of the example requests here:

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31:

I wonder if this task is more or less superseded by work on the Technical Collaboration Guideline. And if not, which parts are left.
(Personally I miss a description of a problem to solve in this task; also because terms like "engagement" can mean a lot of things.)

This (old) task clearly needs and update and precision. As a quick comment, I would say that the TCG currently focuses on ending memory editors, and what this task wants to cover is better engagement with volunteer developers.

This (old) task clearly needs and update and precision. As a quick comment, I would say that the TCG currently focuses on ending memory editors, and what this task wants to cover is better engagement with volunteer developers.

IMHO this task in its current state is neither measurable nor actionable, and its summary feels not strongly related to its description.
I am going to remove the Developer-Advocacy tag from it for the time being as it is unclear to me what exactly is requested from our team.

I don't see anything actionable in this task hence closing.