Automate listing of members of technical steering committee

[derberg]

most up to date description -> https://github.com/asyncapi/.github/issues/47#issuecomment-1046222917

Reason/Context

Our open governance model introduces a TSC that consists of all the CODEOWNERS that want to use their right to have a vote in TSC decisions making process.

We need a bot/github action that will read VOTERS files from all repos, maintain single list, and put it on the website

Description

• get a github action that reacts on any push to master and checkes if voters file was edited. Then reads it and add/remove/modify a voter in the list stored on the website
• get a github action that on a PR level validates modification in VOTERS file and blocks PR in case VOTERS cannot be added to TSC list as they are affiliated with the company that already reached the limit of representation
• decide on structure of VOTERS file
• get a mechanism that collects more details about TSC members (social accounts, hire availability, etc)

[derberg]

I'm having doubts if it makes sense to maintain voters file per repo. Repo user cared about codeowners as this is the group of people that are important gate keepers for giver repo. TSC is for a group of people taking care for entire organization, so I think that actually VOTERS files should be only located in the website or community repos.

Advantage:

• We do not need special action on PR and after push that collects VOTERS but just PR to one repo will have to be created
• The only PR action will have to be on the repo that keeps VOTERS and will do the representation calculation
• One place to manage all details about the VOTER

Disadvantage:

• We anyway might need automation that validates, if a person removed from single CODEOWNER should be removed from VOTERS too because this person was a CODEOWNER in one repo only. This could also be a easy periodic workflow, that runs one a week to check all is in sync, and drops slack alert in case it isn't. Still better than the initial idea I think

Thoughts?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping: It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation. Thank you for your contributions :heart:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping: It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation. Thank you for your contributions :heart:

[derberg]

VOTERS file structure:

- github: derberg
  linkedin: lukasz-gornicki-a621914
  twitter: derberq
  availableForHire: false
  #if this field is not provided, it means the person is an individual contributor
  #if this field is provided, it is used to check if the number of TSC members from one company still allows others to join 
  companyName: Postman
- github: aayushmau5
  linkedin: aayushmau5
  twitter: aayushmau5
  availableForHire: true

in the community repo, we will have one file that lists all TSC members (TSC_MEMBERS.yml), with an additional field, the name of repos (repos) where the given TSC member is a maintainer.

[derberg]

ok, for now we have a basic list that is for now updated manually -> https://github.com/asyncapi/community/blob/master/TSC_MEMBERS.json.

for voting, a temporary solution is to use this mailing list. Until we get some fancy voting app in place, with deadlines, reminders, etc.

Whenever we update this list, we will also have bot updating it in the website -> https://github.com/asyncapi/website/blob/master/config/TSC_MEMBERS.json

---

still missing:

• VOTERS file per repo and then automated building of TSC_MEMBERS.json
• voting app instead of google group
• nice view in the website UI that consumes TSC_MEMBERS.json and renders a beautiful list of all TSC members

[smoya]

for voting, a temporary solution is to use this mailing list.

Would Github Discussions work better than mailing list? You can vote in there and it's more reachable IMHO.

[derberg]

• we wanted a more traditional approach where we are sure "1-more additional GitHub notification about discussion" is not lost among others. Thus email
• yeah, some may say Discussions is more readable but there are plenty of communities still liking traditional mailing group with some UI that shows all emails 🤷🏼

we could definitely include Discussions when we work on voting app. Like a wrapper around? so it is easier for other to vote, but still all is transparent somewhere publicly, definitely an option

[derberg]

ok, the display of TSC members is here -> https://www.asyncapi.com/community/tsc

VOTERS file - I doubt we need it after all

and yeah, voting app 🤔

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[derberg]

What we have atm:

• we build this https://www.asyncapi.com/community/tsc
• this is source https://github.com/asyncapi/community/blob/master/TSC_MEMBERS.json
• source is updated manually by CODEOWNERS that want to be TSC Members
• we have automated check, GH workflow that runs on a PR level to check if new TSC member can be added to the list

What we do not have atm:

1. TSC_MEMBERS.json should be updated automatically:
   • I think VOTERS file we proposed in governance model doesn't make sense as it introduces redundancy. You can have maintainers that maintain 5 repos, and to be added as voters, they would need to be added to VOTERS files in 5 repos, which makes no sense.
   • I think we should rename TSC_MEMBERS.json to MAINTAINERS.json and keep there all folks from CODEOWNERS from all repos. Using GitHub API we can check their names and even info about twitter profile.
   • There would be another property in MAINTAINERS.json that would indicate if person is a TSC member
   • update of MAINTAINERS.json would be triggered by the change in CODEOWNERS in any repo under AsyncAPI
   • the only manual change in MAINTAINERS.json that PR workflow would allow, would be update of existing members in a file, no additions/removals would be allowed because these can be done only if someone is removed or added to CODEOWNERS
   • maintainer would be allowed to manually update MAINTAINERS.json with more social media details + info about TSC membership
   • MAINTAINERS.json would also contain aggregated information about a number of TSC members, per company info, and how many more can be added by given company at a given moment
   • we should store date when maintainer was added to the list
2. Extend TSC members list on website with info about limits, and more info about a company that given TSC member represents, link to website, maybe possible to add logo too? and then some filters?
3. We should drop an email to maintainers that are on the list, that because of the change in limits can now become members of TSC. In case one more person can be added from company A then email goes to person A that is on the list and was added there before person B. There is a cron job that runs again after 2 weeks and if person did not volunteer for TSC membership, next one from the list gets an email.
4. We should have automated communication (twitter) that new members were added to the list of TSC members

For GSoC participants

• You will have a chance to see how discussions are done in Open Source
• You will be driving a possible change in open governance model that will expose you to see how processes in Open Source are manaed
• You will be writing some JS code for automation
• You will need to do work on the website to update the existing view of TSC members
• You will learn GitHub Actions in depts by writing few automation workflows

[ritik307]

@fmvilas @derberg I would like to work on this as part of the Mentorship program. 😊

[darp99]

@fmvilas @derberg Hello sir, i am working for issue #178 "we should have a GH workflow that posts a welcome message to the PR that is merged that contained new TSC member" and for that i am exploring in depth about GH action and github REST and GraphQL API. Also it's related to TSC so i would like contribute on this as a part of "Mentorship Program".

[Namyalg]

Over the past months, I have been contributing to the asyncapi/.github repository and learning about GHA. This is an interesting issue which I want to work on during the mentorship

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[sambhavgupta0705]

Hey @derberg ,I would to participate in GSOC'23 with this issue and would like to more clarification of what voting scheme need to be there?

[octonawish-akcodes]

I am interested in this project issue this GSOC'23

[derberg]

ok folks, as this issue is super old, with conversation history that might make it difficult to follow, I decided to refresh it and create new issue.

closing this one and please follow https://github.com/asyncapi/.github/issues/210 if you are interested