Detach stamp.static() and stamp.compose() from this

[koresar]

Use closure variable instead of this. Stamp function should not depend on bound context. This improves code stability. Stamp behavior gets more predictable.

[unstoppablecarl]

👍 agreed

[koresar]

@unstoppablecarl You have the powers to merge it. :)

[unstoppablecarl]

We should decide on an approval process.

[koresar]

Processes are good in big organisations. In open source projects processes are evil. :) They delay productivity.

If you have any process proposal - go ahead. We'd love to listen.

[unstoppablecarl]

Maybe something like 3 people should review before merging?

[koresar]

Sound okay. But each PR would take about 3 to 5 days to review because there are 4 collaborators here. :)

Let's try be less burocratic. Small safe changes are fine to merge by a single person I think. If a change is significant then let's wait for few people to take a look. Just like I did with the #96

Reasonable?

[troutowicz]

We can do something similar to what FB does for React. Make a tag GH Review: review-needed and one for when reviewers feel it is good to merge GH Review: accepted.

[koresar]

Good idea. Are we big enough to introduce this little complexity in sake of quality?

[troutowicz]

I would say that once you have more than two collaborators on a project, a simple change like this would make PR reviews easier to manage. First person to see the PR adds GH Review: review-needed and could cc someone else to handle the review. Or they could review right away by themselves. Once the reviewer thinks things check out they can add the GH Review: accepted tag and cc someone to handle the merge, or possibly handle the merge themselves.

cc @unstoppablecarl @ericelliott

[koresar]

Sounds okay to me. We can try.

[ericelliott]

For small, non-breaking changes and minor bug fixes, the first reviewer should feel free to merge as long as the build is passing and they've looked over the code and feel confident.

For larger changes such as API additions or breaking changes where broader discussion is warranted, (like #96), I agree that other core contributors should have a chance to weigh in before it hits master. =)

In those cases, we should definitely leave it open for discussion for a few days and give other contributors a chance to weigh in.