Page MenuHomePhabricator

Agreement on when and how communities provide feedback.
Closed, ResolvedPublic

Description

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.

Related Objects

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:

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.

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.

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:

These are all related and are being handled this quarter, no problem.

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.