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.

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

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 atsage@saltstack.com 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

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 atsage@saltstack.com 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

👍