To do: This issue is a staging ground for documenting a robust editorial process for controlling what kind of messaging is pushed to Core.

Comments

hestenet created an issue. See original summary.

sudheesh.r’s picture

sudheesh.r commented

We are waiting for the API details from the Drupal core team.

nod_’s picture

nod_
Primary language French
Location Lille
commented
Version: » 1.x-dev

We should document how things end up in this feed on a d.o page and add a link to that page whenever we display the messages from the feed.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented

From #3206643: Project messaging channel in core (as experimental) the current proposal for governance of the feed is:

Proposed governance:

  • Sign off by a designated Drupal Association staff member
  • Sign off by a Drupal Core product manager (per maintainers.txt)
  • (When relevant) sign off by another key stakeholder - such as a security working group member for announcements related to security issues, for example.

This could be expanded with some more detail, and added to: https://www.drupal.org/governance (this is an old 'book' type documentation section, which itself needs to be migrated to the new documentation content types, but we can ensure the url stays the same for any link we provide in the announcement feed. )

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented
Title: Policy: Document approval process for what appears in the official Drupal project messaging feed » Document approval process for what appears in the official Drupal project messaging feed
Project: Announce » Drupal Community Governance
Version: 1.x-dev »
Component: Documentation » Policies

I think we should move this issue to the Governance project since the goal of this issue is to introduce changes to the governance. That way we can both discuss and file patches here.

I have some questions regarding the proposal in #4:

  1. Are you proposing that the governance will be under Dries, or under the Drupal Association?
  2. Is sign off needed from all of stakeholders or can one of the stakeholders sign off alone?
  3. What is the role of the other maintainer roles if product managers are solely responsible for signing off on the posts?

I'm wondering if the governance would be simplified if we would add some extra flexibility by providing multiple feeds. We would allow the end user to configure which feeds they subscribe to. There could be one feed for Drupal Association communication, and one feed for project related communication by the Drupal core team. Different feeds would have their own governance. That way the Drupal project and Drupal Association would be able to communicate independently about relevant topics to them, and users would receive communication relevant to them. This could be potentially extended with additional feeds in future. Something like the Planet Drupal could be a feed that Drupal sites could subscribe to in future.

rachel_norfolk’s picture

rachel_norfolk
Primary language English
Location UK
commented

If it is project messaging, then it would fall under the governance of the project, surely? Presumably, a good deal of the messaging wouldn't even originate within the Drupal Association, anyway, so there would be no relevant staff to sign off on those?

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented

Based on #6, I'm wondering if the proposal in #4 should list Drupal Association under the "when relevant" group?

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

@laurii I think as a future direction multiple feeds could be interesting. I think the immediate goal of this project was to

(a) support EOL efforts to communicate about EOL of versions of Drupal in one more channel that is evident to admins
(b) help promote minor Drupal core updates (feature updates), thus helping with upkeep of Drupal sites
(c) connect the software back to the Drupal Association and thus promote the DA itself
(d) help promote events and other fund driving things for the Drupal Association (maybe a subgoal of (c) depending on how you look at it)

I think for the initial implementation the goal was to mix these up by design in a way and also to not get bogged down in various abstraction possibilities that could come with arbitrary feeds, multiple feeds, a general messaging framework and whatnot.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented

Big +1 to what Gabor said in #8.

Pretty early on in the initial scoping of the idea we decided that in the interest of getting an initial channel for communication open we should start with a single feed, and consider expanding to multiple feeds as a possible enhancement (including perhaps providing an API that contrib could hook into for their own announcements).

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented
Status: Active » Needs review

A first draft at very simple governance language for this feed. What other elements does this sort of policy need? (Also, is there another policy that could be referenced as a template?)

Governance

Governance of the announcements feed follows a similar principle to other Drupal contribution: the author of the post cannot 'RTBC' the work.

This announcement feed is jointly governed by Drupal core maintainers and the Drupal Association.

  • If the Drupal Association drafts a post, at least one member of the core maintainer team must approve it.
  • If the Drupal core team drafts a post, at least one member of the Drupal Association must approve it.

I am assuming we ultimately update this here: https://www.drupal.org/governance
(Which is a section of docs still needing to be migrated to the new system, but that's a seperate concern)

But for reference, I've also created (currently unpublished) pages to document this and other aspects of the module in the Core Modules documentation section.

Core Module Documentation:

nod_’s picture

nod_
Primary language French
Location Lille
commented
Issue tags: +Project governance

I think that's the right tag for this

dries’s picture

dries commented

I like Tim's proposal in #10. It gives us a good starting point that is simple and fast. Maybe add an escalation option too.

  • If the Drupal Association drafts a post, at least one member of the core maintainer team must approve it.
  • If the Drupal core team drafts a post, at least one member of the Drupal Association must approve it.
  • If there is disagreement between both, the Project Lead can decide.

We can start simple, learn, and expand or clarify as needed.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented
Status: Needs review » Fixed

Confirmed with Dries in the course of another conversation that #12 was intended to be RTBC.

Published the governance policy above in the current 'Governance' book hierarchy:

(The whole governance book needs to be migrated to the new docs types at some point, but until then want to keep this together with the rest of the governance policy).

Also published:

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented

Here is a draft of a suggested first post to already be present in the feed when the features is committed: https://docs.google.com/document/d/1d5Uq1ORQDy5bW_3WAyyorEVuHCtZBBB_aKMt...

It has been available as a draft for about 2 months in: https://www.drupal.org/project/drupal/issues/3206643#comment-14547887

To follow this policy, the next step would be for any 1 member of the core team to approve, and then we can post.

(We may want to make a child issue)

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented

Created child issue for approval of the first post(s): #3343263: Approve first project announcement in core post