comm lead should review changes to guidlines #31
Conversation
Added a section to the communications guidelines requiring that changes to the guidlines must be reviewed by the communications lead. Was inspired by [this section of the contributing guide
communications_guidelines.md
Outdated
| @@ -70,3 +70,6 @@ These guidelines are applicable when acting as a representative of Matplotlib (f | |||
| * Gets over-excited over shiny visualizations - lots of emojis and the like - and encourages folks to share their work. | |||
| * Highlights various parts of the library, especially the more obscure bits and bobbles. | |||
| * Acknowleges that it is a sometimes frustrating tangle of bits & bobbles that can confuse even the folks who work on it & signal boosts their confuzzlment. | |||
|
|
|||
| ## Changes to Guidelines | |||
| Changes to the communications guidelines must be reviewed by the communications lead (currently the community manager) and changes to specific platform guidlines (e.g. twitter, instagram) must be reviewed by the person responsible for that platform when different from the communications lead. If there is no consensus, decisions about community guidelines revert to the communications lead. | |||
There was a problem hiding this comment.
| Changes to the communications guidelines must be reviewed by the communications lead (currently the community manager) and changes to specific platform guidlines (e.g. twitter, instagram) must be reviewed by the person responsible for that platform when different from the communications lead. If there is no consensus, decisions about community guidelines revert to the communications lead. | |
| Changes to the communications guidelines must be reviewed by the communications lead (currently the community manager) and changes to specific platform guidelines (e.g. Twitter, Instagram) must be reviewed by the person responsible for that platform when different from the communications lead. If there is no consensus, decisions about community guidelines revert to the communications lead. |
Is it better to remove the (currently the community manager)-part and move that information to wherever that is listed? In that way, there is no need to change this document if a separate communications lead is appointed.
There was a problem hiding this comment.
maybe, probably, but it would require a separate discussion to factor communications lead out of community management, but I would still want it to be under the community management umbrella, and it would require changes to
- https://github.com/matplotlib/governance/blob/main/people.md
- https://github.com/matplotlib/governance/blob/main/deputy_project_leads.md
and I honestly don't currently have the bandwidth to push on that.
There was a problem hiding this comment.
I don't understand what this paragraph is about, but surely the last sentence should read "communications guidelines" versus "community guidelines".
It was my understanding that all final decisions on anything in the project lay with the steering council, and ultimately the project lead. This seems to give final say to the communications lead? Probably I am misunderstanding.
There was a problem hiding this comment.
but surely the last sentence should read "communications guidelines" versus "community guidelines".
yep
This seems to give final say to the communications lead
Only if there's no consensus, for the very practical reason that the communications folks are the ones carrying out these guidelines. For example, if someone proposes a change to the twitter persona and that change has consensus, whoever is running the account has to either implement that persona or choose to walk; therefore I think it's important to get that input in before any final decision is made and why if there's no consensus the decision should fall to them. The tie breaker language is directly taken from the language about how the API lead has tie-breaking powers on API decisions, no more or less authority than that just parallel 'cause this is also a deputy role. That the API lead is currently on the steering council is I think coincidental for these purposes.
There was a problem hiding this comment.
I totally agree the comm lead should be consulted on comm issues!
For the final authority however I think the API lead wording is problematic as well. If there is deep unresolvable disagreement over some API decision, I would expect the project lead would have final say. Of course a good project lead would tend to defer to the API lead or the communications lead, but in my understanding, final appeal would be to the project lead
There was a problem hiding this comment.
Of course a good project lead would tend to defer to the API lead or the communications lead, but in my understanding, final appeal would be to the project lead
I don't think this language necessarily bars that given our gov docs say it's a BDFL, it's more codifying what we agree is best practice. Also I just think it should be consistent - either DPLs are the first line tie breakers or they're not.
There was a problem hiding this comment.
definitely "first-line" tie breakers!
There was a problem hiding this comment.
Also I looked it up and you approved the PR where the API lead language went in matplotlib/matplotlib#21626
Since the governance says this falls under the community manager's responsibilities, will condense to that for simplicity https://github.com/matplotlib/governance/blob/main/deputy_project_leads.md#community-manager
|
superceded by matplotlib/matplotlib#26703 |
Added a section to the communications guidelines requiring that changes to the guidelines must be reviewed by the communications lead. Also the social media platform lead as appropriate even though my working assumption is any community/communications lead would loop in platform people on things that would affect them. Technically there are sections of this guide that don't need sign off, but it seemed easier to just make it a blanket thing.
I think the requirement should be review not approval because I don't think the communications lead should necessarily dictate the guidelines, but I do think that they should always be looped in since they are responsible for implementing changes.
I was inspired by the api section of the docs which states:
attn: @dopplershift