Clarify maintenance of forked repos

[snim2]

There are a number of RFCs that describe how repositories should be maintained, for example:

• RFC 019
• RFC 028
• RFC 023
• RFC 029
• RFC 036
• RFC 035

However, the RFCs generally don't distinguish between the maintenance of forked repositories and sources (newly created repositories).

With forks, there is sometimes a tension between being able to submit PRs back to the upstream (and so not wanting to change too much code) and wanting to comply with the standards that of the org in which the forked repo lives.

I would suggest that we add some detail to the relevant RFCs to clarify whether they apply to forks, and maybe a good principle to work by would be:

• Community standards (RFCs 028, 036, etc.) usually SHOULD apply to forks, and
• Coding standards (RFCs 019, 023, etc.) MAY apply to forks.

[snim2]

Just a note that this comment thread from PR #192 is also relevant here...

[snim2]

Had a discussion with @rjw1 about this today and bob's view is that forks should NOT count for the RFCs, and should be ephemeral in most cases.

[dragon-dxw]

Had a think about the referenced RFCs one by one:

Community Standards

RFC 028 - Code of Conduct - we don’t expect to own the community if we're forking, feels weird to change? Could add if none.

RFC 036 - Master Branch - Unless there's a compelling reason, it's easy and cheap at the moment we fork.
RFC 029 - Open Source By Default - We are mostly compelled by upstream, so I think this one isn't a problem either way.
(two "follow upstream or improve", one "it's rude not to")

Coding Standards

RFC 035 - Linting Tools - Might cause divergence from upstream which may be painful. Probably inadvisable unless it's a hard fork that never expects to remerge.


RFC 023 - Scripts To Rule Them All - Doing what the project does may be more sensible, but if it doesn't, then it's a strong contender.
RFC 019 - Changelogs - There should be one, somewhere. Could follow upstream or purposefully not for a clean break and two histories.
RFC 079 - Prod Data - Yes. This feels like it's worth doing even if the project doesn't currently do that, it's risky not to.
(one "risky not to", one "inadvisable", two "could, could not, both OK")

TL;DR: It depends; Production Data and Master Branch have strong reasons to; the others we could take a steer from the project or put our own stamp on it.

[snim2]

Thanks @dragon-dxw "Open source by default" is probably not so relevant here, and as it happens we don't have any private forks atm. As you say, the license we inherit cannot easily/sensibly be changed.

[Floppy]

@snim2 I agree that forks shouldn't count for the RFCs. While we might want to apply them, and might do if we can, in general its the project owners choice that counts. However, if we do a hard fork and don't expect to be pushing back, then at that point the RFCs would become applicable.