I want to help here. :)

A similar presentation has been done in 2013 and it needs to be updated.

Do you have the link? I'm curious to know about this starting point.

I have many questions, I hope you don't mind that I share them:

Are we planning to get actual developers involved in this exercise, between now and the Summit?

Do we have a procedure in mind to select tips?

One would say that the most important tips should be connected to the most important problems. Should we start defining problems or...?

The links provided by @Keegan make me think that we have two levels of "tips":

1. Tips about volunteer expectations that anybody willing to have a productive conversation should be aware of.
2. Tips specific "for communicating with communities when developing software".

1 is pretty well covered at Best practices for working with community members, and if something is missing or can be improved, it should be reflected in that wiki page.

2... is there a page addressing 2 specifically?

Instead of putting too much energy in the basic generic tips, maybe it is worth to focus our attention is the (missing?) tips specific for developers (and mainly professional developer teams communicating with non-developer volunteers).

PS: CCing Andre, Lydia, and Birgit, who are also working in this area.

Not that I knew. I'd guess that https://www.mediawiki.org/wiki/Community_Engagement_%28Product%29/Collaboration_process/Draft and https://upload.wikimedia.org/wikipedia/commons/8/8d/WMDE_Technical_Wishes_Concept.pdf have some good items. And I can imagine there's some situation / phase specific info available on some yet-to-discover wiki pages...

In T113490#1765884, @Qgil wrote:

A similar presentation has been done in 2013 and it needs to be updated.

Do you have the link? I'm curious to know about this starting point.

https://docs.google.com/presentation/d/1MsY0F8QEdTrqTKtWKGVIVXa4-Tq7zlTC1_IxLRERWr4/edit#slide=id.p

Seems that document is marked as private, @Trizek-WMF

In T113490#1769483, @Krenair wrote:

Seems that document is marked as private, @Trizek-WMF

Weird. This document is public for all WMF staff.

And the rest of the world? ;-)

In T113490#1770036, @Trizek-WMF wrote:

In T113490#1769483, @Krenair wrote:

Seems that document is marked as private, @Trizek-WMF

Weird. This document is public for all WMF staff.

Yes, I can see it with my own WMF contractor account, but otherwise it's not visible. That means it's private.

I'm very skeptical of a proposal for a presentation that hasn't been done as a Tech Talk yet. See my opinion on good meetings at WikiDev 16 to see why I'm pushing back on an "education" style talk.

In T113490#1770159, @Krenair wrote:

Yes, I can see it with my own WMF contractor account, but otherwise it's not visible. That means it's private.

After a discussion with the original CLs who create this document, they prefer not to share it. Not because there is secrets inside, but just because it is a presentation, just slides with some private jokes which can be misunderstood without context. Sorry.

In T113490#1783615, @RobLa-WMF wrote:

I'm very skeptical of a proposal for a presentation that hasn't been done as a Tech Talk yet. See my opinion on good meetings at WikiDev 16 to see why I'm pushing back on an "education" style talk.

I've edited task description to clarify. The purpose of this talk is both on educational and problem-solving fields.

@RobLa-WMF, I have been discussing with @Tizek-WMF about this session and the steps leading to it. We agree that this is not a presentation, but part of a wider discussion. We have a real problem of communication between developer teams and communities (not always, etc etc) and this is the only proposal for this Summit that discusses interactions with users / communities.

After the edits on the description, I think we can keep it on track for now. The final destination will depend on the progress of the discussion and work.

Is this a useful tip for this list? "When you are editing a wiki as a WMF employee, sign in as a WMF employee".

It is not unfrequent to see anonymous edits on software planning pages, and this doesn't provide a good impression in a context of proficient wiki editors caring a lot about attribution, vandalism, and diffs in general.

In T113490#1844545, @Qgil wrote:

Is this a useful tip for this list? "When you are editing a wiki as a WMF employee, sign in as a WMF employee".

It is not unfrequent to see anonymous edits on software planning pages, and this doesn't provide a good impression in a context of proficient wiki editors caring a lot about attribution, vandalism, and diffs in general.

That really should be part of the internal user account policy, not these tips.

In T113490#1844712, @Krenair wrote:

In T113490#1844545, @Qgil wrote:

Is this a useful tip for this list? "When you are editing a wiki as a WMF employee, sign in as a WMF employee".

It is not unfrequent to see anonymous edits on software planning pages, and this doesn't provide a good impression in a context of proficient wiki editors caring a lot about attribution, vandalism, and diffs in general.

That really should be part of the internal user account policy, not these tips.

+1
Like having a separate account on Phabricator, to avoid confusion between volunteer POV and WMF staff opinion.

In T113490#1847434, @Trizek-WMF wrote:

Like having a separate account on Phabricator, to avoid confusion between volunteer POV and WMF staff opinion.

The policy is about wiki accounts, not for Phabricator. That wouldn't fit like a rule against staff editing without the disclaimers (i.e. while logged out).

At T119030#1859479 I'm recommending this session for the unconference tracks. There hasn't been much discussion before the Summit, and people expressing their interest seem to want to "listen" more that be part of the effort for defining these tips. People motivated by this session could participate in the Unconference context, and then a Tech Talk could be produced with the final presentation. What do you think?

I'm currently working on a way to collect feedback from WMF staff. This collection will be a good start to have a discussion on the way you suggest.

Internal consultation is quite ready (tests ongoing). I plan to submit it by end of week to WMF staff.

WMF internal survey is published.

WMF internal survey first results:

• 53 responses
• Most WMF people interact with volunteer community members via Phabricator or mailing lists. The less used discussion places are MediaWiki.org and Meta.
• 75% are most of the time satisfied by the feedback they receive, 8,2% always satisfied
• 73,5% find people to help them.
• 65% get enough feedback to work
• Most shared best experience (free form): volunteers who just do things (translations, feedback…) for the pleasure without asking for consideration
• Most shared worst experience (free form): anger, rudeness

Etherpad: https://etherpad.wikimedia.org/p/WikiDev16-T113490

(I added some late comments to the pad.)

Points discussed during the Dev Summit 2016:

• Separate what we expect when interacting with communities: feedback about bugs or feedback about features?
• Define the responsabilities on a team, between the PM and people in charge of liaising? Product managment vs. communication?
• "Don't be a jerk" rule -- have someone whose role is to review interactions, and quietly point out to people acting out that they should behave better?
  • Help out with https://www.mediawiki.org/wiki/Code_of_Conduct/Draft
• Give advice on when and how to communicate (relevant channels)
  • A bit outdated, but as a start: https://www.mediawiki.org/wiki/Development_process_improvement/Communications_recommendations
  • Have a centralized place for community feedback, see T98354: Create a central, multilingual hub for community support
• Translate all possible messages, say people can communicate in the language they want
• When a problem/controversy occurs, respond timely in the discussion
• Describe the problem you want to solve (in detail), the goal you want to achieve, the homework you have done, the questions you have (even if you have only broad ideas)
• Have the right tool for the right purpose (talk page or survey?)

Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. If the session in this task took place, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to "resolved". If this session did not take place, change the task status to "declined". If this task itself has become a well-defined action which is not finished yet, drag and drop this task into the "Work continues after Summit" column on the project workboard. Thank you for your help!

Due to a big load of work, the "involve users" step is postponed to end of February.

I find the title of this task ("10 tips for communicating with communities when developing software") grating.

At this point I think that whatever advice we have for developers communicating with communities should be integrated at https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication

In T113490#2670729, @Qgil wrote:

At this point I think that whatever advice we have for developers communicating with communities should be integrated at https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication

Which has already been done by discussing with Keegan.

That task has been split between TCG and Community Insights. The result of Community Insignts will be added to the TCG. Is that task still valid?

I would merge this task to T138339: Create a systematic approach to community engagement for product development teams.