Skip to content

Conversation

@florian-lefebvre
Copy link
Member

@florian-lefebvre florian-lefebvre commented Jan 28, 2026

END OF VOTE: 2025/02/04 2:56 PM CET

  • Updates L2 and TSC responsibilities to be framed as reponsibilities (ie. update verbs)
  • Updates the Project Steward responsibilities to actually be framed as responsibilities, not rights/privileges
    • Although the Project Steward responsibilities section may looks like it contain less things, it is not the case!
    • It rephrases responsibilities to be clearer, and incorporates how/when to use some of these specific rights (eg. "veto for emergencies")
    • This also allow to clarify how services are managed, since the governance did not reflect reality (see Remove the Staff role #65 comments): eg. L3 members having admin rights over the GH org.

So to be clear, no right is removed!

@florian-lefebvre florian-lefebvre changed the title Clarify permissions Clarify Project Steward responsibilities about services access Jan 29, 2026
@florian-lefebvre florian-lefebvre changed the title Clarify Project Steward responsibilities about services access Update responsibilities Jan 29, 2026
@florian-lefebvre florian-lefebvre changed the title Update responsibilities Better frame responsibilities Jan 29, 2026
- Define project direction and planning
- Ability to decide on moderation decisions
- Access to the `*@astro.build` email address
- Create, administer, and manage access to all third-party services/accounts to which the project has access.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was written in a way that allows using services even if Astro the open-source project doesn't own the account. Eg. technically the GH org belongs to CF

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't think of what this might exclude. A generic "administer accounts" seems reasonable to me! With the responsibility to also "create", I think we sidestep the issue where different people had created some of the accounts initially, then left the project. So this seems to cover everything well!

@sarah11918
Copy link
Member

Just a comment that I'm in favour of sections titled "Responsibilities" being actual responsibilities! Thank you for kicking this off, Florian!

GOVERNANCE.md Outdated
- Access to the `*@astro.build` email address
- Create, administer, and manage access to all third-party services/accounts to which the project has access.
- Ensure [voting](#voting) is carried out according to governance, resolve deadlocks, and veto the result of a vote in extreme situations when deemed necessary for the sake of the project.
- Oversee moderation of community spaces such as GitHub and Discord, provide guidance, and enforce the decisions of moderators when necessary.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"provide guidance" is too vague, not sure what responsibility this entails (provide guidance to who? on what?). better to remove or make more explicit, or make more explicit in the #moderation section and then link there, similar to my suggestion on voting.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similarly: "when necessary" what does this mean? is this defined anywhere? probably better to just remove this or just everything after Discord, ... and assume that that's all already covered by the moderation docs, no need to summarize/restate here.

@florian-lefebvre florian-lefebvre marked this pull request as ready for review January 30, 2026 13:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants