Add Separate Members Page

[pertrai1]

To keep the README file informative, I believe that the members page
being separate would help to keep a long running list of members from
over-populating the README.

[wesleytodd]

Probably want to clean these up

[pertrai1]

good catch @wesleytodd

[mcollina]

Can you please remove the list from the README? Also add a link to the new file there.

Moreover, can you make the list in alphabetical order while you are at it?

[pertrai1]

@mcollina @wesleytodd I have fixed README and put the list in alphabetical order.

[mhdawson]

@pertrai1 any chance you can pull in all of the new members who have open PRs and then we can land this once without having to resolve all of the conflicts?

[pertrai1]

You better believe it. Get as many PRs in as possible and I will rebase

[pertrai1]

@mhdawson I have rebased master into this branch with all commits that have been merged. So any PR's still open below this one and above will need to be merged and rebased, or the PR's will have to change with the name being added to MEMBERS.md file.

[pertrai1]

@mhdawson @mcollina @wesleytodd I have changed the MEMBERS.md to list members using all contributors script to make it look cleaner (background is just from VS code markdown preview). This includes all members up to #86 PR. I get a rate limit of adding members so I need to wait a few hours before I can add the members above this commit.

[wesleytodd]

This looks great! And the tool for this is also great!

[mhdawson]

Seems like a good idea. How do we handle the case when people move to "Emeritus". I'm not too worried about that now but want to understand how we'd handle that later on?

[wentout]

Seems like a good idea. How do we handle the case when people move to "Emeritus". I'm not too worried about that now but want to understand how we'd handle that later on?

I think, as it is rendered HTML, it still can be managed manually. Though, yes, bit harder.

[pertrai1]

@mhdawson @wentout maybe we don't rely on the script after this first large round of project members is added. All we would do after have copy and paste markdown to add either team member or "Emeritus". Worse case scenario I can think of.

[mhdawson]

@pertrai1 ok sounds reasonable. Once you get it updated let us know so that we can land and close the requests that have been covered.

[pertrai1]

@mhdawson is there any way I can have access to close PR's as I add a member. I am going over on my limit for the GitHub API having to do this manually. This branch can be merged with all of the people that are listed on current readme as well as some of the PR's that are open. Right now I am getting roughly 5 requests per hour. Let me know what you think.

[ljharb]

@pertrai1 if you add Closes #123 in your OP, when this PR is merged, it will auto-close them.

[pertrai1]

@ljharb so I can list a bunch of PR's right after Closes?

[mhdawson]

I'm not quite sure I understand the part about closing the PRs? Does that interact with the tool. What I was thinking is we'd land and update with all of the people who have made requests and then I'd go through and close the PR's one by one to make sure we'd not missed anybody. But I'm also ok using the Closes and then I can double check after the fact with the closed PRs

[ljharb]

@pertrai1 no, Closes #123. Closes #124. etc.

[pertrai1]

@mhdawson Right now this has all the current members plus the PR's for 100 and above. Any PR's between this one and #100 have not been added yet. I also changed the readme to mention that someone should open an issue where they want to join. If you prefer to stay with PR's, I will revert that change.

[pertrai1]

@mhdawson forget where the readme mentions creating issue. The tool works on those who have contributed so PR's are the way to go.

[mhdawson]

Ok, going to land, what is the next step to getting the rest of the PRs between 64 and 100 addressed? Is it as simple as checking out and running to get an update?

[mhdawson]

IT also seems a number above 100 were not added as well. I closed the ones that I think were added.

[wentout]

And it also seems like some PRs not counted as contribution.
Cause if we are not merging their PRs, but just closing, github counts as no contribution.

Seems like all who will be added after this, have to update their forks and make additional requests about themselves.

Seems it it necessary to reopen this and others closed after #64

all this "Closed" will not count as contribution

I'm telling about this icon

Also I think it will be harder now to make some automation, based on github logins. Because we have no simple list, but full HTML, which have to be parsed to extract the logins. So, we can't just copy and paste full list somewhere.

all of them are not becoming contributors, cause no merge

@mhdawson, @pertrai1 can I reopen, reslove conflits and merge instead ?

[pertrai1]

Sounds good to me if it needs to be reopened so we can flush this out

[pertrai1]

I think once the PR's are merged then generating the new list each time will be much simpler. This first shot was a bit difficult because the PR's were/are not merged yet.

[terary]

I am one of those non-contributors listed above..
Is there anything I can do to help with this?

[pertrai1]

@wentout @mhdawson if we can get the conflicts resolved and merge the PR's, then we can generate again and it will correctly add all contributors. Both of you would have to handle the conflicts and merging and I can help out any way possible.

[wentout]

@pertrai1 I think it is nice solution. Though still, it requires extra time we have to add new PRs of team membership. If there can be some automation, I'd prefere to have simple list for merging new PRs through which members will receive contribution status, and other beautifull auto-generated list from all-contributors. And still, it looks like too complicated if there will be no automation for this. It requires you to spend your time each member addition. So, it must be automated in another way. Each solution wich spends extra time of one of package-maintenance contributors looks odd for me .

[pertrai1]

@wentout I completely understand that point of view. Should there still be a separate members file or revert back to using readme?

[wentout]

@wentout I completely understand that point of view. Should there still be a separate members file or revert back to using readme?

IDN, seems it is up to community, for sure: @mhdawson, @mcollina, what do you think?
I can try to find solution to automate it via github actions, webhooks or something like this.

[mhdawson]

Ok, I think we should just go back to a simple list at this point. What I'd like to do is to land a single PR which updates the README.md to include all of the members for the existing PRs and then we can take another look at the separate page. @wentout would you be able to put together that PR?

[wentout]

@wentout would you be able to put together that PR?

Yes, sure, definetely.

[mhdawson]

@wentout thanks, I'll try to keep an eye out for it so that I can land it soon after you have it ready.