You're awesome! We're giving you commit bits. #3567
Comments
|
Also added @Blaisorblade since he's the one who originally proposed this idea and has contributed some patches in the past. |
|
Wohoo! First of all, thanks! :) This also gives access to edit in the issue tracker. I've missed this in the past when I've seen {mis,un}labeled issues. Great! So you do most development against |
Basically yes, big features are expected to go through code review before merging.
From release branches. For example, all 1.24 releases are made from the 1.24 branch. |
Ah, ok. And the release manager is responsible for merging fixes and updates from master to the release branch for minor releases? |
|
Yeah, at the moment only the release manager is supposed to touch the stable branches. But if that is not working for people we can reconsider. FWIW, I know some people work on big features by running feature branches but my personal style is maintaining patchsets which I continually rebase on HEAD, the idea being that self-contained patches are easier to CR. I'm not sure we should enforce this on everyone though. |
|
CR? Sent from my iPhone
|
|
Code review! |
|
@acfoltzer added! |
|
Wow, this is a very active project! My inbox is already overflowing with Thanks for adding me! On Jul 21, 2016 12:38 AM, "Edward Z. Yang" [email protected] wrote:
|
|
@gelisam Sorry about the spam! If you (or anyone else) don't want to get notifications for ALL tickets, I think the "unwatch" button should work. But also feel free to lurk / ask questions! |
|
Also added @snoyberg since he has contributed patches and bug reports in the past. |
|
Thanks :) |
|
Added @NovaDenizen for #3657 |
|
Added @mmakowski for his past contributions. |
|
Thanks!! |
|
Just found meta:easy for those looking for for ideas to get started: |
|
Added @RyanGlScott for #3697 and #3704. |
|
Added @jaccokrijnen for #3757 |
|
Added @erantapaa for #3765 |
|
Added @brendanhay for #3844. |
|
Added @domenkozar for #5561. |
|
Added @DavidEichmann for #5673. |
|
Added @int-index for #5679. |
|
I can't believe i missed my own commit bits! Thanks! also, great job @hrhino! |
|
Added @earldouglas for #5879 and #5878. |
|
Added @piyush-kurur for #5514. |
|
Added @JoshMeredith for his contributions to #5995. |
|
Added @basvandijk for past contributions. |
|
Added @fendor. |
|
this issue is not active and the commit bit is being given more informally, should be close this? @Mikolaj |
|
Yes, we've followed the spirit of this issue, but made no notes. I think most of the contributors from last year were offered commit bits, though not all accepted. There was a talk about automating this and spicing up so that it's obvious that's a sign a gratitude, not of forcing a responsibility on somebody. However, this requires a new ticket and a volunteer. Let's close. And once more thank you to all people mentioned here. You are awesome indeed. :) |
|
Actually, quite a few people refused the invitation and I'm told others might have felt overwhelmed by notifications from the repo, so it's no longer obvious an unannounced invitation to a repo is token of appreciation and not, e.g,. of assuming the new person is now suddenly responsible for stuff. I guess our traffic has grown too high and also being one of a hundred is not such a distinction any more. I propose we drop the habit and instead try to honour contributors by being uncharacteristically civil and expressing gratitude orally. Thoughts? |
|
or ask the contributor before giving them perms in the pr? |
|
It's a good, net-win practice: it causes no harm but may attract new contributors. As noted, notifications are easy to turn off (or ignore the invite altogether). Sending some standard text that you have this practice and it bears no responsibility, only an opportunity to donate some more of your time, would be welcome. Initially, I was confused when I got the invite, and thought maybe it's a mistake. |
As an outside observer, I fail to discover any tangible benefit of this practice: while it was followed since 2016, by mid 2020 the number of active contributors decreased roughly to one and remained in that precarious state until recently. I do believe that "being uncharacteristically civil" is a key to create a welcoming environment (huge thanks to the current team for this!), and granting commit bits to strangers out of nowhere is irrelevant. There is a clear downside of this practice in terms of security. If I have a write access, I can forge a commit from any author with any message and push it into any branch. There are currently 75 people with write access, which is a huge liability. |
|
I believe we should spread the ability to "garden" (set tags and soforth) to anyone with an accepted PR. Having a smaller pool of people with permission to actually commit merges seems fine at this point. |
|
Yeah, assigning 'triage' rights is pretty harmless. |
|
Well, master and main version branches are protected and nobody, including admins (by default, they can skip it of course) can push directly to them, You need a pr with two approvals. Otoh you (any admin) can always revert any change (even with force pushes if you take care quickly) and revoke permissions. There are no similar protections for triaging so i would say triaging perms can destroy more valuable info: the issue tracker and the metadata associated. You cant revert remove a label for all issues for example. And the time spent by users and maintainers in the issue tracker is as valuable as the time spent in the codebase imho. Otoh give membership helps to build such welcoming environment and helps to avoid an elitist and inaccesible image. Also it encourages the continuation of contributions. That alone will not make it, as it was demonstrated but sure helps. But well i think it is better to simply ask contributors if they want to be and only doing it if they responds affirmatively. EDIT: i agree with many povs from Gabriella about open source and that is one of them: https://github.com/dhall-lang/dhall-lang/blob/master/.github/CONTRIBUTING.md#how-do-i-get-the-commit-bit |
Note that by default 'write' access includes all 'triage' bits.
This is far from bulletproof. An adversary can push a commit, signed by someone else's name, in the middle of a feature branch, when it was already approved, but not merged (e. g., CI has not completed yet). It would be quite difficult to spot it. Git is fundamentally insecure (same to email). |
|
Unfortunately, I haven't found a way to send an invitation text automatically or even via copy-paste. The Setting/Add People menu doesn't have the functionality, I think. There were talks about some plugins that enable this, but it didn't materialize. I haven't found a way to filter contributors based on PR authorship and on commit bits, either, so guessing whom to send to was manual labor as well. Would a snippet in README, similar to what @jneira linked, mentioning triage, "commit bit if really needed" and general gratitude regardless, be a better solution than blanket invite-spam? OTOH, reaching out individually to people is invaluable, but that is happening in discussions in the bug tracker and in the #hackage room. |
Hello @thumphries, @sjakobi, @accraze, @headprogrammingczar, @randen, @aisamanra, @kolmodin, @mightybyte, @gbaz, @garetxe, @komadori, @mgsloan, @lukexi, @mpkh, @pra85, @tvestelind, @corngood, @gelisam,
You're receiving this message because you recently contributed to Cabal. We value your contribution to Cabal, and so in the style of The Pull Request Hack, we are giving you commit bits. There are a few common sense rules about pushing to master (e.g., https://github.com/haskell/cabal#conventions — especially, keep the CI green and PR big changes before pushing), but mostly, be bold!
This is a new experiment for all of us and if there are things that are confusing and unclear please ask, we will try to clarify as much as possible.
P.S. If you know anyone I missed, please let me know.
The text was updated successfully, but these errors were encountered: