Discussion:
[Cucumber] New contributing guidelines
(too old to reply)
aslak hellesoy
2017-08-15 15:13:06 UTC
Permalink
Raw Message
Hi everyone,

In order to make it easier to maintain the Cucumber project we're making
some changes to the contribution guidelines.

== Commit Bit ==

The Cucumber core team recently decided on a liberal commit bit policy for
the repositories under the Cucumber GitHub organisation:

After a contributor gets their first pull request approved and merged, they
are added to the committers tam, which gives them the "commit bit" to all
repositories under the Cucumber organisation. This means they can push
directly to the Cucumber repositories without having to push to their own
forks and wait for someone else to merge it.

Handing out the commit bit is automated:
https://github.com/cucumber/commitbit

We hope this will remove some of the bottlenecks in getting pull requests
merged. In case someone accidentally pushes bad code we can always revert
it.

== Pull Requests ==

We ask that committers work on feature branches and make pull requests,
rather than making commits on the master branch. We also encourage
committers to merge their own pull requests (and others') after someone
from the core team has reviewed and approved the pull request.

== Teams ==

Committers that have been making regular contributions over a period of
time can be invited to join one of the core teams by someone else who is
already on a core team. The team structure is as follows:

committers
+- core
+- aruba
+- cucumber-js
+- cucumber-jvm
+- cucumber-ruby
+- cucumber-ruby-tcl
+- docs
+- gherkin

Contributors can see all the teams and who's a member of what team at
https://github.com/orgs/cucumber/teams - expand a team to see child teams.

People who are a member of any of the teams under core are considered to be
part of the core team. Being part of a core team doesn't give you extra
GitHub powers - it's merely an indication that you're a regular
contributor. It also allows people to mention people in a team in issues,
for example "hey @cucumber-jvm what do you think about...".

If you have made more than 8 commits to a repo in the past year you're
eligible to become member of a core team (someone from the core team can
invite you).

If you stop being active (less than 8 commits in the past year), you may be
removed from the core team. You still have commit rights, you just won't be
listed as a core team member.

(We'll occasionally run `git shortlog -n -s --since "1 year ago"` to see
who should be on the core team).

== Trunk Based Development ==

If you're on the core team, we encourage you to use trunk based development
(https://trunkbaseddevelopment.com/) for minor refactorings and changes.
This simplifies the workflow for the core team, who are the most active
contributors.

If a core team member needs to make more than one commit to make a change
(typically for a bigger change), they should use feature branches and pull
request, just like everyone else.

== Questions and Comments ==

We'd love to hear your thoughts about this process. Based on your feedback
I'll write this up in a more permanent place.

Thanks!
Aslak
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jayson Smith
2017-08-15 15:42:41 UTC
Permalink
Raw Message
Awesome! I'm on board with this. Seeing as I just went through it, I've
also got some ideas on improving the new committer process/info delivery
that I'd like to get implemented too, haven't begun yet though.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Krishna Gundala
2017-08-15 16:50:36 UTC
Permalink
Raw Message
Nice and sounds good for new members who are willing to participate.
Thanks team for coming up with an idea like this.


---

Thanks,

Mohan G
Post by aslak hellesoy
Hi everyone,
In order to make it easier to maintain the Cucumber project we're making
some changes to the contribution guidelines.
== Commit Bit ==
The Cucumber core team recently decided on a liberal commit bit policy for
After a contributor gets their first pull request approved and merged,
they are added to the committers tam, which gives them the "commit bit" to
all repositories under the Cucumber organisation. This means they can push
directly to the Cucumber repositories without having to push to their own
forks and wait for someone else to merge it.
Handing out the commit bit is automated: https://github.com/
cucumber/commitbit
We hope this will remove some of the bottlenecks in getting pull requests
merged. In case someone accidentally pushes bad code we can always revert
it.
== Pull Requests ==
We ask that committers work on feature branches and make pull requests,
rather than making commits on the master branch. We also encourage
committers to merge their own pull requests (and others') after someone
from the core team has reviewed and approved the pull request.
== Teams ==
Committers that have been making regular contributions over a period of
time can be invited to join one of the core teams by someone else who is
committers
+- core
+- aruba
+- cucumber-js
+- cucumber-jvm
+- cucumber-ruby
+- cucumber-ruby-tcl
+- docs
+- gherkin
Contributors can see all the teams and who's a member of what team at
https://github.com/orgs/cucumber/teams - expand a team to see child teams.
People who are a member of any of the teams under core are considered to
be part of the core team. Being part of a core team doesn't give you extra
GitHub powers - it's merely an indication that you're a regular
contributor. It also allows people to mention people in a team in issues,
If you have made more than 8 commits to a repo in the past year you're
eligible to become member of a core team (someone from the core team can
invite you).
If you stop being active (less than 8 commits in the past year), you may
be removed from the core team. You still have commit rights, you just won't
be listed as a core team member.
(We'll occasionally run `git shortlog -n -s --since "1 year ago"` to see
who should be on the core team).
== Trunk Based Development ==
If you're on the core team, we encourage you to use trunk based
development (https://trunkbaseddevelopment.com/) for minor refactorings
and changes. This simplifies the workflow for the core team, who are the
most active contributors.
If a core team member needs to make more than one commit to make a change
(typically for a bigger change), they should use feature branches and pull
request, just like everyone else.
== Questions and Comments ==
We'd love to hear your thoughts about this process. Based on your feedback
I'll write this up in a more permanent place.
Thanks!
Aslak
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Paolo Ambrosio
2017-08-16 06:08:01 UTC
Permalink
Raw Message
Let me start by thanking Giel for the amazing job at maintaining Cucumber-CPP.


On Tue, Aug 15, 2017 at 4:13 PM, aslak hellesoy
Post by aslak hellesoy
Hi everyone,
In order to make it easier to maintain the Cucumber project we're making
some changes to the contribution guidelines.
Not sure if I've missed any conversation in one of the several
channels we have (Google Groups, Gitter, Slack, ... others?), but for
something this important I would have loved to have an agreement
before it was implemented. Or perhaps I misunderstood what you were
trying to do, thinking that it would be activated only for some
projects (e.g. documentation).
Post by aslak hellesoy
== Commit Bit ==
The Cucumber core team recently decided on a liberal commit bit policy for
After a contributor gets their first pull request approved and merged, they
are added to the committers tam, which gives them the "commit bit" to all
repositories under the Cucumber organisation. This means they can push
directly to the Cucumber repositories without having to push to their own
forks and wait for someone else to merge it.
I am very much against this policy.

I don't think that one merged PR, perhaps correcting a typo, is
enough. The hard part in PR reviews is to go through the quality and
make sure that it fits in the big picture, it is tested enough, etc.
The same people that you want now to merge PRs, could have left
reviews and tried to attract a maintainer's attention.

Also creating branches in the main repository surely can't be good.
Look at Cucumber-JVM: most branches are stale and it would be much
easier if they were in the author's repository as experiments. In my
opinion this is going to cause a lot of maintenance.
Post by aslak hellesoy
https://github.com/cucumber/commitbit
We hope this will remove some of the bottlenecks in getting pull requests
merged. In case someone accidentally pushes bad code we can always revert
it.
Sure, but it can easily spiral out of control. If maintainers didn't
have time to merge a PR, they probably have no time to read what has
been merged and fix it (and there is no way to ask for changes once a
PR gets merged).
Post by aslak hellesoy
== Pull Requests ==
We ask that committers work on feature branches and make pull requests,
rather than making commits on the master branch. We also encourage
committers to merge their own pull requests (and others') after someone from
the core team has reviewed and approved the pull request.
== Teams ==
Committers that have been making regular contributions over a period of time
can be invited to join one of the core teams by someone else who is already
committers
+- core
+- aruba
+- cucumber-js
+- cucumber-jvm
+- cucumber-ruby
+- cucumber-ruby-tcl
+- docs
+- gherkin
Contributors can see all the teams and who's a member of what team at
https://github.com/orgs/cucumber/teams - expand a team to see child teams.
People who are a member of any of the teams under core are considered to be
part of the core team. Being part of a core team doesn't give you extra
GitHub powers - it's merely an indication that you're a regular contributor.
It also allows people to mention people in a team in issues, for example
If you have made more than 8 commits to a repo in the past year you're
eligible to become member of a core team (someone from the core team can
invite you).
If you stop being active (less than 8 commits in the past year), you may be
removed from the core team. You still have commit rights, you just won't be
listed as a core team member.
(We'll occasionally run `git shortlog -n -s --since "1 year ago"` to see who
should be on the core team).
== Trunk Based Development ==
If you're on the core team, we encourage you to use trunk based development
(https://trunkbaseddevelopment.com/) for minor refactorings and changes.
This simplifies the workflow for the core team, who are the most active
contributors.
If a core team member needs to make more than one commit to make a change
(typically for a bigger change), they should use feature branches and pull
request, just like everyone else.
== Questions and Comments ==
We'd love to hear your thoughts about this process. Based on your feedback
I'll write this up in a more permanent place.
Thanks!
Aslak
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
MP Korstanje
2017-08-16 14:16:36 UTC
Permalink
Raw Message
The sprawl of stale branches for cucumber-jvm has mostly been cleared up and is completely a legacy from about 5 years ago.


Recently branches have been much shorter lived. Presently I have no reason to worry.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Paolo Ambrosio
2017-08-16 18:09:57 UTC
Permalink
Raw Message
Post by MP Korstanje
The sprawl of stale branches for cucumber-jvm has mostly been cleared up and is completely a legacy from about 5 years ago.
That was exactly my point! Many people creating branches on a
repository to work on their own stuff that never gets raised as a PR,
and lives forgotten in the main repo, instead of their own, and with
no one knowing what to do with them.
Post by MP Korstanje
Recently branches have been much shorter lived. Presently I have no reason to worry.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rien Korstanje
2017-08-16 18:30:01 UTC
Permalink
Raw Message
All those branches were by a single author. :D Currently I am treating them
as design docs.
Post by MP Korstanje
The sprawl of stale branches for cucumber-jvm has mostly been cleared up
and is completely a legacy from about 5 years ago.

That was exactly my point! Many people creating branches on a
repository to work on their own stuff that never gets raised as a PR,
and lives forgotten in the main repo, instead of their own, and with
no one knowing what to do with them.
Post by MP Korstanje
Recently branches have been much shorter lived. Presently I have no reason to worry.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/cukes/MvoWkpRR95o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
aslak hellesoy
2017-08-16 19:06:49 UTC
Permalink
Raw Message
Post by MP Korstanje
Post by MP Korstanje
The sprawl of stale branches for cucumber-jvm has mostly been cleared up
and is completely a legacy from about 5 years ago.
That was exactly my point! Many people creating branches on a
repository to work on their own stuff that never gets raised as a PR,
and lives forgotten in the main repo, instead of their own, and with
no one knowing what to do with them.
It's entirely possible that this will happen, although I think the risk is
low. I prefer to cross that bridge when we get there, perhaps by
introducing a new policy saying that committers should create PRs for
branches in their own forks, and can merge them themselves once approved.

But for now let's try to do it all in one repo. The benefit of that is that
I can push new commits onto someone else's branch - it becomes easier to
collaborate.
Post by MP Korstanje
Post by MP Korstanje
Recently branches have been much shorter lived. Presently I have no
reason to worry.
Post by MP Korstanje
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups "Cukes" group.
Post by MP Korstanje
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
MP Korstanje
2017-08-16 14:21:16 UTC
Permalink
Raw Message
@Aslak, could you modify the commit bit bot in such a way it revokes the commit bit after a year or so when it has gone unused. This should reduce some of the risks that happen when people fade away I think.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dennis Günnewig
2017-08-20 06:53:53 UTC
Permalink
Raw Message
Hey,

I share the worries of Paolo. Having a contributor only submitting a PR
which fixes a typo in a README doesn't give you that much information about
a developers' coding style etc. Though I see the point in make the projects
more "attractive" for Newcomers. What about flagging PRs taken into account
with a Github tag? Or shall we just wait for 6 months and then see if the
policy needs some modification?

I disagree that the core team should not have "extra powers". No one should
have the permission to remove a repo besides very few people, but what
about the other settings like "web hooks". Now I'm not even able to set
topics on the Aruba project and need to reach out for help. Without giving
trusted members of the community a bit more "power" you introduce another
bottleneck.

Cheers,

Dennis
Post by Paolo Ambrosio
Let me start by thanking Giel for the amazing job at maintaining Cucumber-CPP.
On Tue, Aug 15, 2017 at 4:13 PM, aslak hellesoy
Post by aslak hellesoy
Hi everyone,
In order to make it easier to maintain the Cucumber project we're making
some changes to the contribution guidelines.
Not sure if I've missed any conversation in one of the several
channels we have (Google Groups, Gitter, Slack, ... others?), but for
something this important I would have loved to have an agreement
before it was implemented. Or perhaps I misunderstood what you were
trying to do, thinking that it would be activated only for some
projects (e.g. documentation).
Post by aslak hellesoy
== Commit Bit ==
The Cucumber core team recently decided on a liberal commit bit policy
for
Post by aslak hellesoy
After a contributor gets their first pull request approved and merged,
they
Post by aslak hellesoy
are added to the committers tam, which gives them the "commit bit" to
all
Post by aslak hellesoy
repositories under the Cucumber organisation. This means they can push
directly to the Cucumber repositories without having to push to their
own
Post by aslak hellesoy
forks and wait for someone else to merge it.
I am very much against this policy.
I don't think that one merged PR, perhaps correcting a typo, is
enough. The hard part in PR reviews is to go through the quality and
make sure that it fits in the big picture, it is tested enough, etc.
The same people that you want now to merge PRs, could have left
reviews and tried to attract a maintainer's attention.
Also creating branches in the main repository surely can't be good.
Look at Cucumber-JVM: most branches are stale and it would be much
easier if they were in the author's repository as experiments. In my
opinion this is going to cause a lot of maintenance.
Post by aslak hellesoy
https://github.com/cucumber/commitbit
We hope this will remove some of the bottlenecks in getting pull
requests
Post by aslak hellesoy
merged. In case someone accidentally pushes bad code we can always
revert
Post by aslak hellesoy
it.
Sure, but it can easily spiral out of control. If maintainers didn't
have time to merge a PR, they probably have no time to read what has
been merged and fix it (and there is no way to ask for changes once a
PR gets merged).
Post by aslak hellesoy
== Pull Requests ==
We ask that committers work on feature branches and make pull requests,
rather than making commits on the master branch. We also encourage
committers to merge their own pull requests (and others') after someone
from
Post by aslak hellesoy
the core team has reviewed and approved the pull request.
== Teams ==
Committers that have been making regular contributions over a period of
time
Post by aslak hellesoy
can be invited to join one of the core teams by someone else who is
already
Post by aslak hellesoy
committers
+- core
+- aruba
+- cucumber-js
+- cucumber-jvm
+- cucumber-ruby
+- cucumber-ruby-tcl
+- docs
+- gherkin
Contributors can see all the teams and who's a member of what team at
https://github.com/orgs/cucumber/teams - expand a team to see child
teams.
Post by aslak hellesoy
People who are a member of any of the teams under core are considered to
be
Post by aslak hellesoy
part of the core team. Being part of a core team doesn't give you extra
GitHub powers - it's merely an indication that you're a regular
contributor.
Post by aslak hellesoy
It also allows people to mention people in a team in issues, for example
If you have made more than 8 commits to a repo in the past year you're
eligible to become member of a core team (someone from the core team can
invite you).
If you stop being active (less than 8 commits in the past year), you may
be
Post by aslak hellesoy
removed from the core team. You still have commit rights, you just won't
be
Post by aslak hellesoy
listed as a core team member.
(We'll occasionally run `git shortlog -n -s --since "1 year ago"` to see
who
Post by aslak hellesoy
should be on the core team).
== Trunk Based Development ==
If you're on the core team, we encourage you to use trunk based
development
Post by aslak hellesoy
(https://trunkbaseddevelopment.com/) for minor refactorings and
changes.
Post by aslak hellesoy
This simplifies the workflow for the core team, who are the most active
contributors.
If a core team member needs to make more than one commit to make a
change
Post by aslak hellesoy
(typically for a bigger change), they should use feature branches and
pull
Post by aslak hellesoy
request, just like everyone else.
== Questions and Comments ==
We'd love to hear your thoughts about this process. Based on your
feedback
Post by aslak hellesoy
I'll write this up in a more permanent place.
Thanks!
Aslak
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups
Post by aslak hellesoy
"Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by aslak hellesoy
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
aslak hellesoy
2017-08-21 15:22:27 UTC
Permalink
Raw Message
Post by Dennis Günnewig
Hey,
I share the worries of Paolo. Having a contributor only submitting a PR
which fixes a typo in a README doesn't give you that much information about
a developers' coding style etc.
That's true, and I don't care ;-) I'd rather have lots of active
contributors who occasionally push bad code than none who push nothing.
Undo is easy.

People pushing bad code isn't currently a problem. Long lead times and too
many open issues is the biggest problem:

https://github.com/cucumber/github-issue-stats/blob/master/CUCUMBER.md

Though I see the point in make the projects more "attractive" for
Post by Dennis Günnewig
Newcomers. What about flagging PRs taken into account with a Github tag? Or
shall we just wait for 6 months and then see if the policy needs some
modification?
I disagree that the core team should not have "extra powers". No one
should have the permission to remove a repo besides very few people, but
what about the other settings like "web hooks". Now I'm not even able to
set topics on the Aruba project and need to reach out for help. Without
giving trusted members of the community a bit more "power" you introduce
another bottleneck.
Good point Dennis - I've fixed that. Anyone in the core team now has admin
rights.

Aslak
Post by Dennis Günnewig
Cheers,
Dennis
Post by Paolo Ambrosio
Let me start by thanking Giel for the amazing job at maintaining Cucumber-CPP.
On Tue, Aug 15, 2017 at 4:13 PM, aslak hellesoy
Post by aslak hellesoy
Hi everyone,
In order to make it easier to maintain the Cucumber project we're
making
Post by aslak hellesoy
some changes to the contribution guidelines.
Not sure if I've missed any conversation in one of the several
channels we have (Google Groups, Gitter, Slack, ... others?), but for
something this important I would have loved to have an agreement
before it was implemented. Or perhaps I misunderstood what you were
trying to do, thinking that it would be activated only for some
projects (e.g. documentation).
Post by aslak hellesoy
== Commit Bit ==
The Cucumber core team recently decided on a liberal commit bit policy
for
Post by aslak hellesoy
After a contributor gets their first pull request approved and merged,
they
Post by aslak hellesoy
are added to the committers tam, which gives them the "commit bit" to
all
Post by aslak hellesoy
repositories under the Cucumber organisation. This means they can push
directly to the Cucumber repositories without having to push to their
own
Post by aslak hellesoy
forks and wait for someone else to merge it.
I am very much against this policy.
I don't think that one merged PR, perhaps correcting a typo, is
enough. The hard part in PR reviews is to go through the quality and
make sure that it fits in the big picture, it is tested enough, etc.
The same people that you want now to merge PRs, could have left
reviews and tried to attract a maintainer's attention.
Also creating branches in the main repository surely can't be good.
Look at Cucumber-JVM: most branches are stale and it would be much
easier if they were in the author's repository as experiments. In my
opinion this is going to cause a lot of maintenance.
Post by aslak hellesoy
https://github.com/cucumber/commitbit
We hope this will remove some of the bottlenecks in getting pull
requests
Post by aslak hellesoy
merged. In case someone accidentally pushes bad code we can always
revert
Post by aslak hellesoy
it.
Sure, but it can easily spiral out of control. If maintainers didn't
have time to merge a PR, they probably have no time to read what has
been merged and fix it (and there is no way to ask for changes once a
PR gets merged).
Post by aslak hellesoy
== Pull Requests ==
We ask that committers work on feature branches and make pull requests,
rather than making commits on the master branch. We also encourage
committers to merge their own pull requests (and others') after someone
from
Post by aslak hellesoy
the core team has reviewed and approved the pull request.
== Teams ==
Committers that have been making regular contributions over a period of
time
Post by aslak hellesoy
can be invited to join one of the core teams by someone else who is
already
Post by aslak hellesoy
committers
+- core
+- aruba
+- cucumber-js
+- cucumber-jvm
+- cucumber-ruby
+- cucumber-ruby-tcl
+- docs
+- gherkin
Contributors can see all the teams and who's a member of what team at
https://github.com/orgs/cucumber/teams - expand a team to see child
teams.
Post by aslak hellesoy
People who are a member of any of the teams under core are considered
to be
Post by aslak hellesoy
part of the core team. Being part of a core team doesn't give you extra
GitHub powers - it's merely an indication that you're a regular
contributor.
Post by aslak hellesoy
It also allows people to mention people in a team in issues, for
example
Post by aslak hellesoy
If you have made more than 8 commits to a repo in the past year you're
eligible to become member of a core team (someone from the core team
can
Post by aslak hellesoy
invite you).
If you stop being active (less than 8 commits in the past year), you
may be
Post by aslak hellesoy
removed from the core team. You still have commit rights, you just
won't be
Post by aslak hellesoy
listed as a core team member.
(We'll occasionally run `git shortlog -n -s --since "1 year ago"` to
see who
Post by aslak hellesoy
should be on the core team).
== Trunk Based Development ==
If you're on the core team, we encourage you to use trunk based
development
Post by aslak hellesoy
(https://trunkbaseddevelopment.com/) for minor refactorings and
changes.
Post by aslak hellesoy
This simplifies the workflow for the core team, who are the most active
contributors.
If a core team member needs to make more than one commit to make a
change
Post by aslak hellesoy
(typically for a bigger change), they should use feature branches and
pull
Post by aslak hellesoy
request, just like everyone else.
== Questions and Comments ==
We'd love to hear your thoughts about this process. Based on your
feedback
Post by aslak hellesoy
I'll write this up in a more permanent place.
Thanks!
Aslak
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups
Post by aslak hellesoy
"Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by aslak hellesoy
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dennis Günnewig
2017-08-30 19:47:52 UTC
Permalink
Raw Message
Post by aslak hellesoy
Good point Dennis - I've fixed that. Anyone in the core team now has
admin rights.

Thanks Aslak.
Post by aslak hellesoy
Post by Dennis Günnewig
Hey,
I share the worries of Paolo. Having a contributor only submitting a PR
which fixes a typo in a README doesn't give you that much information about
a developers' coding style etc.
That's true, and I don't care ;-) I'd rather have lots of active
contributors who occasionally push bad code than none who push nothing.
Undo is easy.
People pushing bad code isn't currently a problem. Long lead times and too
https://github.com/cucumber/github-issue-stats/blob/master/CUCUMBER.md
Though I see the point in make the projects more "attractive" for
Post by Dennis Günnewig
Newcomers. What about flagging PRs taken into account with a Github tag? Or
shall we just wait for 6 months and then see if the policy needs some
modification?
I disagree that the core team should not have "extra powers". No one
should have the permission to remove a repo besides very few people, but
what about the other settings like "web hooks". Now I'm not even able to
set topics on the Aruba project and need to reach out for help. Without
giving trusted members of the community a bit more "power" you introduce
another bottleneck.
Good point Dennis - I've fixed that. Anyone in the core team now has admin
rights.
Aslak
Post by Dennis Günnewig
Cheers,
Dennis
Post by Paolo Ambrosio
Let me start by thanking Giel for the amazing job at maintaining Cucumber-CPP.
On Tue, Aug 15, 2017 at 4:13 PM, aslak hellesoy
Post by aslak hellesoy
Hi everyone,
In order to make it easier to maintain the Cucumber project we're
making
Post by aslak hellesoy
some changes to the contribution guidelines.
Not sure if I've missed any conversation in one of the several
channels we have (Google Groups, Gitter, Slack, ... others?), but for
something this important I would have loved to have an agreement
before it was implemented. Or perhaps I misunderstood what you were
trying to do, thinking that it would be activated only for some
projects (e.g. documentation).
Post by aslak hellesoy
== Commit Bit ==
The Cucumber core team recently decided on a liberal commit bit policy
for
Post by aslak hellesoy
After a contributor gets their first pull request approved and merged,
they
Post by aslak hellesoy
are added to the committers tam, which gives them the "commit bit" to
all
Post by aslak hellesoy
repositories under the Cucumber organisation. This means they can push
directly to the Cucumber repositories without having to push to their
own
Post by aslak hellesoy
forks and wait for someone else to merge it.
I am very much against this policy.
I don't think that one merged PR, perhaps correcting a typo, is
enough. The hard part in PR reviews is to go through the quality and
make sure that it fits in the big picture, it is tested enough, etc.
The same people that you want now to merge PRs, could have left
reviews and tried to attract a maintainer's attention.
Also creating branches in the main repository surely can't be good.
Look at Cucumber-JVM: most branches are stale and it would be much
easier if they were in the author's repository as experiments. In my
opinion this is going to cause a lot of maintenance.
Post by aslak hellesoy
https://github.com/cucumber/commitbit
We hope this will remove some of the bottlenecks in getting pull
requests
Post by aslak hellesoy
merged. In case someone accidentally pushes bad code we can always
revert
Post by aslak hellesoy
it.
Sure, but it can easily spiral out of control. If maintainers didn't
have time to merge a PR, they probably have no time to read what has
been merged and fix it (and there is no way to ask for changes once a
PR gets merged).
Post by aslak hellesoy
== Pull Requests ==
We ask that committers work on feature branches and make pull
requests,
Post by aslak hellesoy
rather than making commits on the master branch. We also encourage
committers to merge their own pull requests (and others') after
someone from
Post by aslak hellesoy
the core team has reviewed and approved the pull request.
== Teams ==
Committers that have been making regular contributions over a period
of time
Post by aslak hellesoy
can be invited to join one of the core teams by someone else who is
already
Post by aslak hellesoy
committers
+- core
+- aruba
+- cucumber-js
+- cucumber-jvm
+- cucumber-ruby
+- cucumber-ruby-tcl
+- docs
+- gherkin
Contributors can see all the teams and who's a member of what team at
https://github.com/orgs/cucumber/teams - expand a team to see child
teams.
Post by aslak hellesoy
People who are a member of any of the teams under core are considered
to be
Post by aslak hellesoy
part of the core team. Being part of a core team doesn't give you
extra
Post by aslak hellesoy
GitHub powers - it's merely an indication that you're a regular
contributor.
Post by aslak hellesoy
It also allows people to mention people in a team in issues, for
example
Post by aslak hellesoy
If you have made more than 8 commits to a repo in the past year you're
eligible to become member of a core team (someone from the core team
can
Post by aslak hellesoy
invite you).
If you stop being active (less than 8 commits in the past year), you
may be
Post by aslak hellesoy
removed from the core team. You still have commit rights, you just
won't be
Post by aslak hellesoy
listed as a core team member.
(We'll occasionally run `git shortlog -n -s --since "1 year ago"` to
see who
Post by aslak hellesoy
should be on the core team).
== Trunk Based Development ==
If you're on the core team, we encourage you to use trunk based
development
Post by aslak hellesoy
(https://trunkbaseddevelopment.com/) for minor refactorings and
changes.
Post by aslak hellesoy
This simplifies the workflow for the core team, who are the most
active
Post by aslak hellesoy
contributors.
If a core team member needs to make more than one commit to make a
change
Post by aslak hellesoy
(typically for a bigger change), they should use feature branches and
pull
Post by aslak hellesoy
request, just like everyone else.
== Questions and Comments ==
We'd love to hear your thoughts about this process. Based on your
feedback
Post by aslak hellesoy
I'll write this up in a more permanent place.
Thanks!
Aslak
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups
Post by aslak hellesoy
"Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by aslak hellesoy
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...