Properly list the organization members

[UlisesGascon]

While working on expressjs/express#5600, it was suggested that we list the organization members and teams to make it easier to identify the individuals helping the project (cc: @CBID2 @mertcanaltin). Node.js provides a great example of this (see).

Historically, only the TC members were listed in the community section of the website (see). Recently, in the Security WG, we decided to include the team members of the teams in the README.md file (see), and we also documented the Captains initiative in the CONTRIBUTING.md (see).

I think it's a great practice for our organization to maintain an updated list of all the people who have been part of the organization, both currently (active) and over the years (emeriti). It is a fantastic recognition of the effort invested by many individuals and a great exercise in transparency.

In the past, we had some discussions about this, and if I remember correctly, we thought that keeping the list in the main repository README.md might generate a lot of PRs and so on. I personally don't think this is an issue, as Node.js follows this practice and even includes those commits in the release notes, so the changelog also reflects the organization changes.

In my opinion, we should keep both lists updated (website and the Express README.md) and include all the teams and roles, what do you think?

[CBID2]

While working on expressjs/express#5600, it was suggested that we list the organization members and teams to make it easier to identify the individuals helping the project (cc: @CBID2 @mertcanaltin). Node.js provides a great example of this (see).

Historically, only the TC members were listed in the community section of the website (see). Recently, in the Security WG, we decided to include the team members of the teams in the README.md file (see), and we also documented the Captains initiative in the CONTRIBUTING.md (see).

I think it's a great practice for our organization to maintain an updated list of all the people who have been part of the organization, both currently (active) and over the years (emeriti). It is a fantastic recognition of the effort invested by many individuals and a great exercise in transparency.

In the past, we had some discussions about this, and if I remember correctly, we thought that keeping the list in the main repository README.md might generate a lot of PRs and so on. I personally don't think this is an issue, as Node.js follows this practice and even includes those commits in the release notes, so the changelog also reflects the organization changes.

In my opinion, we should keep both lists updated (website and the Express README.md) and include all the teams and roles, what do you think?

I agree @UlisesGascon. It'll keep things accurate and make it easier for people to contact those who want to join the triage team

[mertcanaltin]

I agree, if it is appropriate, I can make an improvement if I reach the contact list 🚀

[wesleytodd]

In the past, we had some discussions about this, and if I remember correctly, we thought that keeping the list in the main repository README.md might generate a lot of PRs and so on.

I think my concern was more about all the other stuff mainly. I did think that the triage team which gets alot of "add me" PRs who then never respond to a single issue to help with the effort was the other concern. With the new Triage team policy that should go away and so maybe it is enough.

In my opinion, we should keep both lists updated (website and the Express README.md) and include all the teams and roles, what do you think?

That said, I am neutral on this because it is just another thing to keep updated. Could we instead ask someone to write a small action to use the api to sync members from their teams first? It should be really easy to do and would mean we can just invite folks to the team and all the docs and stuff are automatically updated. This is a much better long term play imo than manually doing it.

[wesleytodd]

I can make an improvement if I reach the contact list

@mertcanaltin one thing I think maybe our docs are not making clear to folks: Everyone can start doing the work (the main thing we care about) before being on the list or team. For the Triage team that just means helping with issues. Respond to users questions, go read old ones and see if there is a good solution, etc. And while you cannot yet close or label them, you can always ping someone who can if you find one which needs that action.

In addition to all that, doing that work is a great way to learn about the project and get involved and helping quickly. There is no official thing from the project you need to help in that way! So please feel free to follow repos and start helping!

[mertcanaltin]

@wesleytodd I opened a pr 🚀
#5619

[UlisesGascon]

With the new Triage team policy that should go away and so maybe it is enough.

Yep, with the new nomination process in place this is not an issue now :)

That said, I am neutral on this because it is just another thing to keep updated. Could we instead ask someone to write a small action to use the api to sync members from their teams first? It should be really easy to do and would mean we can just invite folks to the team and all the docs and stuff are automatically updated. This is a much better long term play imo than manually doing it.

Agree, I will like to have an automation for this but I think that we can do the first addition manually. I know that Node.js has some automation regarding this (ref1, ref2) at least to update the lists when a member got removed from certain teams.

[jonchurch]

The Node approach uses git history to create its list of Active / Inactive collaborators. So simply folks w/ a commit tied to their names in the past 12 months.

✨✨ Here's a summary of how they do it:

Overview of the Process

Triggering the Action: The GitHub action is scheduled to run weekly, specifically every Monday at 4:05 AM UTC. It can also be triggered manually if needed. This ensures regular checks without needing manual initiation.

Setting Up the Environment:

• The workflow begins by checking out the repository using a specific version of the actions/checkout GitHub Action.
• It then sets up Node.js using the actions/setup-node action, ensuring that the script runs with the desired Node.js version (the latest LTS in this case).

Identifying Inactive Collaborators:

• A custom Node.js script (tools/find-inactive-collaborators.mjs) is executed. This script uses git commands to pull commit history data since a specified date (12 months ago by default) to identify active contributors.
• It compares the list of active contributors from the git logs with the list of collaborators mentioned in the README.md file. Those not found in the commit logs are deemed inactive.

Generating Outputs:

• For inactive collaborators, the script formats a list and prepares to update the README.md file by moving these collaborators to an "emeritus" section, acknowledging their past contributions but noting their current inactive status.

Handling Changes:

• If the script finds any inactive collaborators, it modifies the README.md file accordingly and then a GitHub Action step uses another action (gr2m/create-or-update-pull-request-action) to create or update a pull request with these changes.
• This pull request includes a pre-formatted message and is labeled appropriately, making it ready for review and merge by the team.

Review and Merge:

• Team members, particularly those with administrative rights like the Technical Steering Committee (TSC), are notified to review the pull request. This PR includes a link to offboarding documentation, helping to ensure that any necessary administrative tasks are completed.

If we want to do something like Collaborators, we can essentially lift the Node code.

If we want to do something which is Github team based, we can also do that. But will need to write a new action unless someone can find an existing one. It's not too hard to create said action, but we will need a Github Auth token, since the https://api.github.com/orgs/expressjs/teams endpoint requires auth. I think gitub actions give you one, but we will want to make sure we scope it down to just reading public info.

[mertcanaltin]

The Node approach uses git history to create its list of Active / Inactive collaborators. So simply folks w/ a commit tied to their names in the past 12 months.

✨✨ Here's a summary of how they do it:
If we want to do something like Collaborators, we can essentially lift the Node code.

If we want to do something which is Github team based, we can also do that. But will need to write a new action unless someone can find an existing one. It's not too hard to create said action, but we will need a Github Auth token, since the https://api.github.com/orgs/expressjs/teams endpoint requires auth. I think gitub actions give you one, but we will want to make sure we scope it down to just reading public info.

I am +1 to this idea and I will investigate how I can do it, I have updated the document to have manual pensioner lists