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. https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels is the starting point, and now https://phabricator.wikimedia.org/project/view/1015/ 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.

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

2. 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.

Thank you! My presentation in Wikimania last year:

• The Wikimedia open source project and you (video, slides)

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.

In T85590#1016030, @Qgil wrote:

Common principles of prioritization are good to avoid unproductive fights. https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels 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:

https://www.mediawiki.org/wiki/Team_Practices_Group/How_To_Engage_With_TPG

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: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

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.

In T85590#2749455, @Qgil wrote:

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.