On Wed, 31 Aug 2016, Ray Satiro via curl-library wrote:

> I salute your intent but you also kind of just did the opposite and worked
> unilaterally here, where you could have discussed this with existing team
> members first.

Quite so and you're dead right. That wasn't very team spirit of me. I need to
learn to post my intent first and then proceed to allow feedback before I
move...

Sorry about that. But let me elaborate on why I think this is the right way.

> For example I would have said I think measuring someone on the number of
> commits alone is not good. I also don't like a 'public' number because it
> could encourage an adversary to reach that just to get push rights. I have
> no objection though, I recognize a lot of those names and let's see how it
> shakes out. Going forward I do think existing team members should have some
> discussion before new team members are added.

First, I'm not sure this is going to be repeated exactly this way in the
future so the public number isn't that special (but sure, we could actually
setup a sort of ground rule that we'd do something like this in some sort of
repeated fashion). Then, it counts actual, accepted and merged commits so they
were indeed fine changes (with or without our edits of course). If someone
wants to "gain the system" by providing more patches in that style, that's a
net gain for us.

In general people don't ask for getting push rights since people are most nice
and don't want to be a bother, plus just submitting pull requests is a decent
way to merge things and most people won't see themselves as really needing the
push rights. This move was a bigger sort of invte on my behalf to show that we
value them and that they were already part of the family.

I think a larger team of persons who feel they can drive things forward is
worth the occasional mishap when someone lands something wrong or don't follow
our procedures (I'm certainly known myself for breaking a thing or two by
irregular intervals). I've heard about good turnouts in projects where they
routinely offer everyone push rights after their first landed patch and
similar.

People tend to grow when given responsibility.

> A lot of the unwritten rules like linear history and commit style should be
> documented to make it easier for new team members, so I started a wiki page
> for it https://github.com/curl/curl/wiki/push-access-guidelines

That's just awesome and something I've wanted for a while as well. Great!

It is in fact a good resource for any contributor to curl to read. The commit
message style, the use of branches, 'make checksrc' etc apply to us all.

(and I like seeing that the wike is getting some love)

> Another idea - a mailing list that we can use to mail just team like
> curl-team@ when there's an administrative issue or question etc

I've thought about this too, but I'm generally reluctant to create more lists
untill we really have the need. My hope is that curl-library can keep
satisfying our needs even when it comes to administrative issues. Of course,
for things and subjects that aren't meant for the public this list isn't
suitable - is that enough for a new list or can we stick to just private
emails for that? I don't know. But if we need to, I can of course setup
another list.

Thanks for this feedback Ray. I'm grateful you're on the team and working to
keep us in shape!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html