SEP 27: Create Community Advisory Board

[cassandrafaris]

This is the initial SEP about creating a Community Advisory Board.

[cassandrafaris]

I've updated the SEP's formatting to make it easier to read.

[terminalmage]

There is mention of nomination, but no details on that process. Perhaps it should be added to the "unresolved questions" section?

[cachedout]

This seems like an unnecessarily long list of unresolved questions. Is there a reason they aren't included in the proposal itself? It's very hard to review a proposal that doesn't include many specifics.

[sagetherage]

Yes, I agree there are many unresolved questions. Please give us your input and feedback on these :)

[sagetherage]

Open Hour Meeting Notes

• https://github.com/saltstack/community/wiki/Open-Hour-Agendas-and-Notes:-2020-09#2020-09-24 this SEP was mentioned and quoted here: "Team focus: getting ready for code freeze, drafting Advisory Board SEP, Docs Jam work"
• https://github.com/saltstack/community/wiki/Open-Hour-Agendas-and-Notes:-2020-10#2020-10-01 mentioned and quoted here: "Cassandra just opened a SEP - SEP 27: Create Community Advisory Board #36 - for Community Advisory Board SEP 27: Create Community Advisory Board. This is the initial SEP about creating a Community Advisory Board."
• https://github.com/saltstack/community/wiki/Open-Hour-Agendas-and-Notes:-2020-10#existing-seps-sep-25-add-runtime-registers-to-salt-sep-26-package-salt-with-tiamat-sep-27-create-a-community-advisory-board "The next step for SEP 27 is to make some formatting changes to the SEP. Since it's a change in governance, it's on hold until the VMWare acquisition is finalized."

[ScriptAutomate]

The scope here seems large and vague:

Members will discuss and influence the following areas: SEPs, Working Groups, technical decisions, and best practices

• Technical decisions and best practices: I don't know what this would mean, and how this would influence workflows around salt development, releases, docs, etc. Best practices in regard to Python development? In regard to Salt documentation and/or guidance on Salt implementation, or?
• Is this purely around salt, or is this around Salt Project? This is considered the Salt Project community, which involves the entire open source ecosystem on GitHub and GitLab organizations. Does the responsibilities around discussing/influencing technical decisions and best practices now extend?
• Would the CAB be responsible for Code of Conduct enforcement? Or perhaps with putting together a team associated with enforcement?
  • If so: in the event of a code of conduct report, who's responsibility does it become? What are the next steps when it comes to investigative action? etc.
• What do they advise on or review? Are they more of a SEP review and SEPherd board? And upon a SEP being accepted, if it is, do they help communicate awareness around the SEP process for SEPs? Do they help make community members aware of accepted but unimplemented SEPs?

[sagetherage]

Here are some of my thoughts, but not opening a formal review. I would like to hear from others as well who are interested in applying for the board.

• Frequency of meeting and how often is really a question for the board itself, but please give us input here. Would anyone join something as often as monthly? Is quarterly meeting enough?

• Candidates need to be active contributors to the project. I asked in the Open Hour MAR-04 to submit an email to me at [email protected] with why you want to join, your thoughts on what the purpose of the board is, and some sort of identification (I put resume or LinkedIn profile, but I would also take other forms of identification such as github/gitlab profile).

• Keeping the board's work organized and prioritized can also be determined by the board itself, but we will give a place for this occur. ATM I would expect this to be here in a new directory: https://github.com/saltstack/community. and the sharing of agenda and details of meeting minutes would adhere to our current practice of 2 days prior agenda items will be set and at the end of meetings we will leave ad-hoc time and suggestions of new agenda items, the board can park agenda items for later dates as they fit. Meeting minutes will be posted 2 business days after the meeting and documentation like this will live in the community repo.

• Board member's tenure is likely to be decided by the board itself, as well as if specific positions are assigned or tasked to be held for a tenured amount of time. At this time, this detail can be decided by the board members in collaboration with the Core Team.

• We will continue to use the communication platforms of Slack, IRC, public google groups and the community repo. The board will determine official communication once formed.

• The board will take direction and work in collaboration with the Project's Core team on activities, projects, goals and objectives. A project charter template exists for the Working Groups and likely this would be similarly adopted fo the CAB and created with its members once formed. It can be found here: https://github.com/saltstack/community/blob/master/working_groups/community-temp-proj-chrtr.md

[terminalmage]

Going to use your feedback as a jumping-off point.

Frequency of meeting and how often is really a question for the board itself, but please give us input here. Would anyone join something as often as monthly? Is quarterly meeting enough?

I think that this would depend on release cadence, but to me quarterly feels too infrequent. Monthly seems reasonable to me.

Candidates need to be active contributors to the project. I asked in the Open Hour MAR-04 to submit an email to me at [email protected] with why you want to join, your thoughts on what the purpose of the board is, and some sort of identification (I put resume or LinkedIn profile, but I would also take other forms of identification such as github/gitlab profile).

Done.

Keeping the board's work organized and prioritized can also be determined by the board itself, but we will give a place for this occur. ATM I would expect this to be here in a new directory: https://github.com/saltstack/community. and the sharing of agenda and details of meeting minutes would adhere to our current practice of 2 days prior agenda items will be set and at the end of meetings we will leave ad-hoc time and suggestions of new agenda items, the board can park agenda items for later dates as they fit. Meeting minutes will be posted 2 business days after the meeting and documentation like this will live in the community repo.

This seems reasonable, the only question I would have is how access to that repo is managed. It would be nice to have the repo be publicly visible, but have comment/PR submission be restricted to Salt Core Team and CAB members. However, I'm not familiar with GitHub's access control options, and whether or not something like this is doable.

Board member's tenure is likely to be decided by the board itself, as well as if specific positions are assigned or tasked to be held for a tenured amount of time. At this time, this detail can be decided by the board members in collaboration with the Core Team.

This seems fine as well. I think that definition can be worked out at a later date.

We will continue to use the communication platforms of Slack, IRC, public google groups and the community repo. The board will determine official communication once formed.

Slack does have the ability to create invite only channels, so Slack can be used for this kind of communication.

The board will take direction and work in collaboration with the Project's Core team on activities, projects, goals and objectives. A project charter template exists for the Working Groups and likely this would be similarly adopted fo the CAB and created with its members once formed. It can be found here: https://github.com/saltstack/community/blob/master/working_groups/community-temp-proj-chrtr.md

👍

[sagetherage]

This SEP was part of discussion at the Open Hour MAR-04 YouTube and at the weekly Core Team's Planning meeting, today. The details of who and what the board does are something to be worked out in the implementation phase that proceeds the initial acceptance of the SEP. The proposal is to come to rough consensus on an idea to then start planning on how to implement, it is NOT to say it will be implemented or how. That being said, there was initial interest in the formation of a CAB, however, this SEP has not had much community support or conversation except to ask the Core Team when and how they will implement. This must be driven by the community in collaboration with the Core Team.

[terminalmage]

Going to use your feedback as a jumping-off point.

Frequency of meeting and how often is really a question for the board itself, but please give us input here. Would anyone join something as often as monthly? Is quarterly meeting enough?

I think that this would depend on release cadence, but to me quarterly feels too infrequent. Monthly seems reasonable to me.

Candidates need to be active contributors to the project. I asked in the Open Hour MAR-04 to submit an email to me at [email protected] with why you want to join, your thoughts on what the purpose of the board is, and some sort of identification (I put resume or LinkedIn profile, but I would also take other forms of identification such as github/gitlab profile).

Done.

Keeping the board's work organized and prioritized can also be determined by the board itself, but we will give a place for this occur. ATM I would expect this to be here in a new directory: https://github.com/saltstack/community. and the sharing of agenda and details of meeting minutes would adhere to our current practice of 2 days prior agenda items will be set and at the end of meetings we will leave ad-hoc time and suggestions of new agenda items, the board can park agenda items for later dates as they fit. Meeting minutes will be posted 2 business days after the meeting and documentation like this will live in the community repo.

This seems reasonable, the only question I would have is how access to that repo is managed. It would be nice to have the repo be publicly visible, but have comment/PR submission be restricted to Salt Core Team and CAB members. However, I'm not familiar with GitHub's access control options, and whether or not something like this is doable.

Board member's tenure is likely to be decided by the board itself, as well as if specific positions are assigned or tasked to be held for a tenured amount of time. At this time, this detail can be decided by the board members in collaboration with the Core Team.

This seems fine as well. I think that definition can be worked out at a later date.

We will continue to use the communication platforms of Slack, IRC, public google groups and the community repo. The board will determine official communication once formed.

Slack does have the ability to create invite only channels, so Slack can be used for this kind of communication.

The board will take direction and work in collaboration with the Project's Core team on activities, projects, goals and objectives. A project charter template exists for the Working Groups and likely this would be similarly adopted fo the CAB and created with its members once formed. It can be found here: https://github.com/saltstack/community/blob/master/working_groups/community-temp-proj-chrtr.md

👍

[janae417]

Recommend closing this SEP and not implementing due to lack of community interest and lack of need for a CAB.

[welcome]

Congratulations on your first PR being merged! 🎉