Who gets added to the github D Language organization?

[Mike Franklin]

On Saturday, 22 December 2018 at 17:23:06 UTC, Basile B. wrote:
> On Thursday, 20 December 2018 at 23:14:30 UTC, H. S. Teoh wrote:
>> On Thu, Dec 20, 2018 at 11:03:59PM +0000, Your Name via 
>> Digitalmars-d wrote:
>>> How does one get added to the github dlang organization? 
>>> https://github.com/orgs/dlang/people
>>
>> By having a history of contributions to D, and being noticed 
>> by somebody with the right to add you.
>>
>>
>> T
>
> At least one former member was added after requesting the 
> membership (Mike Franklin, source: i asked him the exact same 
> question on IRC).

That is incorrect (you might be misrecalling our conversation, or 
I may have said something that could have been misinterpreted).  
I never requested membership.  I'm not sure why I was added.  
There were 4 things I was doing at the time I was asked to join.

1. I was working on https://github.com/dlang/dmd/pull/7079
2. I was reviewing PRs even though I was not on the team.
3. I was trying to re-submit PRs that had gone largely unreviewed 
and needed to be rebased, but the author had given up on.
4. I complained that PRs were not being reviewed in a timely 
manner.

I like to think that I was asked to join because of 4, and Andrei 
got irritated with me thinking "OK, you think these PRs should be 
reviewed, you do it", so he added me.  If that was his 
motivation, I made good on it, and helped reduce the PR queue 
from around 180 to about 130 in the months of November and 
December 2017.  His motivation could have simply been because of 
1, 2. or 3 though.

If you want to be on the team, here's what I suggest:
*  Review PRs with professionalism.  If you find issues, make 
them known.  If you think they look good, mark them approved.  
Don't just point out problems, help the contributors get it right 
by suggesting implementation details, even if you have to submit 
a competing PR.  Ensure the PR has sufficient test coverage.  You 
don't need to be on the team to do any of this.
*  Submit PRs of your own.  Specifically, browse bugzilla looking 
for issues that you think you can fix.  Walter loves it when we 
fix regressions.
* Rebase, and resubmit orphaned PRs that you think are good 
solutions, and try to carry them across the finish line.  You 
need to babysit your PRs.  Make sure they're always green 
(passing the test suite), or you probably won't get much 
attention.

Don't do the following:
* Make unproductive comments in the PR discussion that just add 
to the indecision of the PR, or derail the conversation.  
Remember, you're trying to do one of two things to the PR 1) get 
it accepted, or 2) get it closed.  Be sure your comments bring 
the PR closer to one of those fates.  We also want to ensure PRs 
have necessary accompanying documentation such as a DDoc header 
comment for public members, a spec update, and/or a changelog 
entry.
* Submit PRs for new features, unless its a feature Walter and/or 
Andrei have specifically asked for.  Such PRs require approval by 
Walter or Andrei, so other team members can't merge them even if 
they want to, and Walter and Andrei likely won't even look at 
them.  Use the DIP process to support your PR instead.
* Argue with reviewers.  They're trying to help you.  Accommodate 
them and address their concerns without any whining.

My 2 cents anyway.

Mike