This will outline when teams can expect community feedback and how they do it, whether it's through product talk pages, bug reporting, Village pump posts, emails, that sort of thing.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Qgil | T128448 Technical Collaboration quarterly goals for April - June 2016 | |||
Resolved | Keegan | T138339 Create a systematic approach to community engagement for product development teams | |||
Resolved | Keegan | T131883 Communication workflows between WMF Product teams and Wikimedia communities | |||
Resolved | Keegan | T132643 Agreement on when and how communities provide feedback. |
Event Timeline
This looks like a good start. Some of the language is a bit stilted and needs improvement. There's also duplication between this subpage and Agreement2 and possibly other subpages. Please let me know when these subpages are unified. One there's a single document, we can do a comprehensive read-through and figure out what needs to be reworked.
I think https://meta.wikimedia.org/wiki/Experiments is relevant here.
I think "Product development guidance" is a decent page title to consider.
There are a lot of Phabricator Maniphest tasks. Here's a partial list:
- T131883: Communication workflows between WMF Product teams and Wikimedia communities
- T113490: 10 tips for communicating with communities when developing software
- T124288: Communication channels between communities and teams involved in the product development process
- T132622: Agreement on when and how Product teams communicate
- T132643: Agreement on when and how communities provide feedback.
- T125805: WMF product development process 1.0
- T125806: Consolidate the WMF product development process overview
- T125807: Consolidate the Understand subpage of the product development process
- T125808: Consolidate the Concept subpage of the product development process
- T125809: Consolidate the Plan subpage of the product development process
- T125810: Consolidate the Develop subpage of the product development process
- T125811: Consolidate the Release subpage of the product development process
- T125812: Consolidate the Maintain subpage of the product development process
- T125815: Consolidate the Communities subpage of the product development process
And in case you're like "oh, that's not so bad," here are another four tasks:
Some practical questions that maybe this draft could answer:
When a team launches a call for feedback, how long should that call last before considered concluded?
This is a guideline, so we are not defining hard deadlines, but this is a question that I have heard frequently. Something like
At least two weeks, up to four weeks if there are ongoing discussions. At that point, blockers and other open discussions should be identified and tracked as part of the regular development cycle.
The idea is that communities have enough time to respond, and a clear time frame avoids dragging everybody's attention for too long, or leaving calls for feedback open, without anybody knowing how to interpret silent / the last status.
What is the most useful way for communities to provide feedback?
This is a guideline for communities as well, and it can help them provide feedback in a way that is more effective to push their agenda, and more helpful for the development teams. Something like
Feedback from individual volunteers and communities is more effective when
- it is concise and points to specific problems that can be isolated and reproduced
- the attention is put on blockers, separating them from smaller issues or other suggestions
- the reasoning is based on principles, previous agreements, and other objective arguments -- neutral point of view and use of references is just as useful here
- the tone is respectful and friendly, treating the development team as any other community members.
Eventually, all useful feedback must be reflected in actionable tasks at the team's project in Phabricator. The closest the community feedback gets to that format, the easiest it is to discuss problems and their solutions.
These will be unified, yes. Thank you for the review - there should be some intentional duplication on a few points. It'll be easier once it's a single document as you mention, I'll be sure to let you know.
I think https://meta.wikimedia.org/wiki/Experiments is relevant here.
I think so too.
I think "Product development guidance" is a decent page title to consider.
There's merit to this. The TC Guidelines are to be best practices that really should be followed as best as product teams can, but at the end of the day we can't practically instruct all aspects of software development like that - "guidelines" seems to imply that we can instruct. Guidance is more friendly. Slightly important bike-shedding, I'll talk it over with others. Thanks.
There are a lot of Phabricator Maniphest tasks. Here's a partial list:
- T131883: Communication workflows between WMF Product teams and Wikimedia communities
- T113490: 10 tips for communicating with communities when developing software
- T124288: Communication channels between communities and teams involved in the product development process
- T132622: Agreement on when and how Product teams communicate
- T132643: Agreement on when and how communities provide feedback.
These are all related and are being handled this quarter, no problem.
- T125805: WMF product development process 1.0
- T125806: Consolidate the WMF product development process overview
- T125807: Consolidate the Understand subpage of the product development process
- T125808: Consolidate the Concept subpage of the product development process
- T125809: Consolidate the Plan subpage of the product development process
- T125810: Consolidate the Develop subpage of the product development process
- T125811: Consolidate the Release subpage of the product development process
- T125812: Consolidate the Maintain subpage of the product development process
- T125815: Consolidate the Communities subpage of the product development process
Ehhhhhhh these were inspired by the WMF product development process draft and the status of that draft. As it is remaining a draft for now, you can pay little mind to these tasks as we work on the Guid(ance/lines).
And in case you're like "oh, that's not so bad," here are another four tasks:
Hey, one of these is done!
In all seriousness, these will get organized better at some point. So much Phabricator overlap.
Assembled in https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication , this individual task is done.