search

elm-community / guidelines

guidelines for *-extra contributors
33 stars 24 forks source link

Guidelines for Changes to Repos Maintained by Others #75

Closed prikhi closed 3 years ago

prikhi commented 7 years ago

@elm-community/maintainers

I initially had these as comments to #74, but it's a bit off topic for that issue:

I think it would be good to discuss how members should treat repositories that they are not maintainers of. Someone on Slack notified #general that the tests for list-extra had started failing. I saw this message & was able to push a fix within 3 minutes of the message. I acted this quickly because list-extra had no maintainer. I'm not sure what I would have done if there was a maintainer. Should I have made a PR and let the tests continue to fail until the official maintainer merged the request? Is it OK to push emergency fixes like this? Is that even considered an "emergency fix"? Where do we draw the line?

Earlier in my tenure, I merged a small PR(I think it was to fix a spelling error or a doc example where the function had it's arguments switched) and the maintainer said "you should really let me do these things". It seemed like an obvious merge to me & I was simply trying to ease the maintenance burden for the maintainer, let them spend their free time/energy on requests that required an actual review. Personally, I don't mind if others help maintain or merge simple requests in the repos I maintain, but it'd be nice to know what is acceptable for other maintainers/repos. Maybe that's a per-maintainer thing, or a per-repository thing.

Can we come up with a list of exceptions to the rules laid out in the Manifesto? Are there members or repos that are open to sharing more of the workload?

The obvious one is an issue affecting the entire Elm ecosystem; Noah didn't wait 7 days before fixing lazy-list, right? Did he wait for a response from the maintainer?

What about small spelling errors, obviously wrong documentation/examples, or failing CI? Maybe opening an issue afterwards would make it more palatable? Like "hey I merged these changes because they were obviously wrong, you should review what I merged when you have some free time".

I'm not trying to take away power from maintainers, I'm more thinking of this like: I've got some free time, so I'll review(& merge?) these tiny/inconsequential/obvious fixes so that when the official maintainer has free time, they can spend it on the real issues.

I'm not saying "this is how it should be", but more wondering what other think about it. I don't want to step on anyone's toes.

Just trying to gauge opinions on this & wondering if we can come up with a common list of reasons it would be OK to bypass the "make a PR & ping the maintainer" process when dealing with repositories that we don't maintain. Or possibly a list of repos whose maintainers are OK with more liberal committing/merging from non-maintainers.

Totally fine w/ people saying "it's fine the way it is", just thought this would be good to discuss while we're discussing #74.

jaapz commented 7 years ago

I don't think laying down lots of rules and exceptions for these kinds of things is really going to help much. Maybe a simple rule like "check with the official maintainer before doing stuff, if they don't respond within a reasonable time span, check with someone else in the elm-community group".

oldfartdeveloper commented 7 years ago

I tend to agree w/ Jaap; let the maintainer know what you want to you want to do. The maintainer guidelines specify that the maintainer should check no less frequently than every 5 days.

On Fri, Jun 2, 2017 at 12:26 AM, Jaap Broekhuizen notifications@github.com wrote:

I don't think laying down lots of rules and exceptions for these kinds of things is really going to help much. Maybe a simple rule like "check with the official maintainer before doing stuff, if they don't respond within a reasonable time span, check with someone else in the elm-community group".

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/elm-community/Manifesto/issues/75#issuecomment-305711057, or mute the thread https://github.com/notifications/unsubscribe-auth/AAET9H25g9B8bp1Xpy391q1jCtpVVvfwks5r_7kVgaJpZM4NtdKV .

-- Scott Smith

http://twitter.com/_ofd (OldFartDeveloper)