[Vote ended on 2024-04-13] Adding a core team member to the steering commitee

This came up in today’s community WG meeting (see the logs) - We’ve wanted more core team involvement in the Steering Committee. @sivel joined the meeting today and I officially nominated him to the SC (just to get that process started).

The interesting part of this is the proposal that the core team rotate members of their team to the SC every quarter. I think some of this may have been discussed at Fossdem, but in general we should discuss a couple of things:

  1. Can we get a nomination vote going so sivel can be part of official votes? His rotation will last til the end of May. The next person will go through September so that we’re aligning on typical calendar quarters.
  2. Can we/should we consider a “core slot” on the Steering Committee so that we don’t have to vote every 3 months on a new person from that team?
1 Like

At FOSDEM and/or CfgMgmtCamp (I’m not 100% sure anymore, it has been some time ago) there has been a bit of discussion about having someone from Core (potentially a rotating member, to avoid too much load for every single Core member) in SC. I kind of lost track of this (too much going on since then), but this never got officially discussed by the SC so far. I guess there has been some misunderstanding of what’s the current state of this.

In any case, I don’t think we should specially vote on sivel (or at least not yet) since the aim is not to have a specific Core member in SC (and then re-vote every couple of months, or however often the rotation happens), but first decide/discuss on whether we want a rotating member from Core in SC or not. (Pinging @SteeringCommittee so that nobody misses this discussion.)

I personally think this is a good idea - so far SC is disjoint from Core and there are always topics which have some kind of overlap (semantic markup is the first that comes to my mind, or documentation in general), and having a better connection would be great. (Especially since nowadays we have more fragmentation in communication channels.)

Also I think a rotating seat is a good idea, since a) it allows Core to always be present without depending on a specific person to be present (said person could be on vacation, sick, could be leaving Core, be too busy because of some Core internal thing, …), and b) we have contact to all Core team members (without all of them having to be active all the time).

What would have to be clear is which Core member is currently representing Core on this seat. My proposal is that we have a thread in the Forum where the currently active memer is announced, and we leave it to Core to organize how they want to handle the schedule (which probably will be some time-based schedule, up to things like PTO etc.).

Right now the only situations where we must know who is representing Core on SC (and make sure only one Core member represents Core on SC) is during votes. In all other situations, Core members, SC members, and community members are basically equal.

What do you all think?


Sounds good to me but we should document how we handle the rotation. I’m thinking whatever logic here makes a person an SC member so the vote works, plus updating docs (or else just put in ‘core team member’ in the docs so we don’t need to generate a PR every few months.).

1 Like

I think it would be a good idea to have someone from the core team in the SC, even if they rotate every couple of months. I also think we shouldn’t vote on the person in question every time. But we probably should vote on this in general.

However, there are a couple of questions:

  • A lot of discussions (and all the votes!) are happening here in the forum. So the core team member would have to have an account here.
  • How will we get informed when a rotation takes place, that is how do we now when to remove a core member from @SteeringCommittee and add another one? @felixfontein proposed a thread in the Forum where the currently active member is announced. Would this be OK or does anyone has another idea?
  • Do we want to document the current core representative in Current Steering Committee members? Or is it OK to have an anonymous “core team representative” there?

In my opinion having “Core team representative” on that list is fine, to avoid constantly having to edit that list (and backporting the changes).

IMO it’s up to Core as long as a) the way includes a log (could be a commit log in a git repository, or the sequence of posts in a forum thread, or …) so it’s clear who was the representative at which time, and b) we get notifications when the current representative changes (could be via PRs in a GitHub repo, watching new messages in a forum topic, …).

That definitely should be a requirement (I would even say: already is a requirement) since we require all SC members to have a forum account anyway. (Most Core team members already have an account here I think.)

1 Like

Yes, I agree. But maybe we should document that there’s a “special” SC member, that is there’s a “seat” or whatever you want to call it, for core and they’re rotating every couple of months in Joining the Steering Committee and maybe also in Current Steering Committee members.

AFAIR someone told me that core didn’t want to use the forum as a (yet another) communication channel. That’s why I wanted to mention this. Maybe I’m remembering wrong, maybe they changed their mind… however, if they have accounts here everything’s fine :person_shrugging:

This wouldn’t be in one place (repo or forum thread), but how about mentioning this on Bullhorn and / or the weekly community meeting? Would this be an alternative? Or maybe something that would be worth to do additionally?

1 Like

I’m +1 for trying to have a core team member

+1 for rotating. We imo should vote on this rotation and not on every single core member when rotating. Also we should update our SC guides to describing this scheme of changing team representatives, anyone wants to do it? I can if no volunteers.


We have the member list and adding just “Core team member/representative” to it SGTM

We could add to what Felix suggested “and to be added to the SC forum group”.
In this case, there’ll be no opportunity to get in, w/o having the account i think.

Any volunteers to start a PR to discuss and vote on? If not, i could try, will wait a couple of days for volunteers;)

1 Like
  1. +1 to having rotating Core member
  2. I think it’s OK to just vote on the process, and not every individual
  3. Announce via Forum as suggested above
  4. Even when not logged in Steering committee - Ansible displays current members, so lets use that page rather than a hard coded list of current members.

I wanted to create a PR, but then I wasn’t really sure how to describe things. If you think you have a good idea for a start, I think it would help if you open a PR. Maybe it’s easier to discuss about this if we have a particular proposal.

1 Like

Hi folks, I am catching up on this and I can’t shake the feeling that we seem to be discussing what other people will do, without them.
We want more “core” involvement in the SC. Do they want to get more involved? Do they have time for it? Without some initiative from core members in that direction I feel we can come with anything - reasonable or otherwise - but there will be no real engagement.


Yes, that is context that was missing. It was recommended a few months ago by a community member directly to the Core team that it may be a good idea for us to be a part of the SC. Through some discussions over that time, we made an internal proposal about how we could accomplish that. This topic is somewhat a direct result of that.

For the duration of the rotation, the Core team representative will be available to participate in SC discussions on the forum and matrix, or wherever else input may be needed.


Created a PR [Needs SC vote before merging] Steering Committee: team membership by Andersson007 · Pull Request #1237 · ansible/ansible-documentation · GitHub please take a look ASAP as i’ll be on PTO since Thursday.
I suggest keeping it simple not thinking about all possible scenarios prematurely.
Please take a look. Then we can start a vote.


I am open to the idea—it would be great to have more interaction between the Core team and the community—but I have a few questions:

  • The Core team representative is there to represent the Core team’s interests and not necessarily the community at large, right?
  • Is the Core team subject to the SC’s decisions? For example, it would not make sense for the SC to vote that Core must merge some PR and maintain the code for the long term, but what about if we decide that the forum is the new place for community discussions and release announcements? Will the Core team follow that SC decision?
  • Will the Core representative have the same participation requirements that other members have? Will the representative vote on all or most topics even if they do not directly pertain to Core?
  • Who will handle switching over forum permissions and such? We want to make sure that only the active Core representative is part of the @SteeringCommittee group.

Just like I imagine all other SC members, the representative is representing their own opinions. It may just happen in this case that the opinion will sometimes represent the concensus of the whole core team. This will not always be the case, as some things may not require larger discussion, and the individual representative will be free to vote as they see fit.

The Core project is not governed by the SC. This is not planned to open oversight into what the core team does or does not do from this perspective. Just think of the representative as any other community member. However, as mentioned above:

Yes, the goal isn’t to just vote on things we care about, it is to be involved in the same way any other SC member is.


I’ll add this comment to the PR as well, but I feel we should put a ‘minimum rotation time’ in the guidelines. As an example, the initial core suggestion was every two months. I suggested quarterly would be easier to track, since we do have to make changes (such as the forum voting rights updates, documentation repo rights, etc).

That said, this ‘minimum serving time’ should apply to all SC members so maybe it’s a separate discussion/vote?

I think it’s time to vote on the PR documenting / implementing this.

Since this is the Easter weekend and some people might be on PTO, let’s keep the vote open until April 13th. This should give people enough time to vote.

The options are quite simple: Merge or don’t merge.

Steering Committee vote
  • Accept / merge the PR
  • Reject / don’t merge the PR
0 voters
Community vote
  • Accept / merge the PR
  • Reject / don’t merge the PR
0 voters

The vote ended today. 8 steering committee and 8 community members voted in favor of merging the PR and allowing a team to become part of the SC. The team will be represented by a (possibly rotating) member of said team.

There were no votes against this.


@mariolenz thanks for organizing the vote!

I’ve added @sivel to the group, welcome to the club:)

Thanks everyone!