Follow

C4Social was created to solve two problems (not enough developers on the fediverse and slow development pace) with the hypothesis that the Collaborative Code Construction Contract (C4) offered a compelling solution.

Core to the C4 is that code is merged not on its content but on the problem it addresses. So from the first moments, feeding the process meant finding code which addresses valid problems. Upstream is therefore the first place you look… and there we found and merged 35 PRs between the two forks.

As people joined, some concerns were raised with this practice:

* First, that such PRs might be work-in-progress and that by merging code before upstream maintainers, we would be taking on additional risk on a patch which may still receive comments and changes.
* Second, if more changes are made and then the code is then merged upstream, we may have conflicts to resolve which might make merging not worth the extra maintenance.
* Third, the author of the patch may be surprised that their code is used on a fork.

Today, there are another dozen or so PRs to look at so this is a good time throw a question out there. Are there other concerns that should be raised about this practice? If you make PRs, would you want to be pinged by a fork?

· · Web · 0 · 1 · 0
Sign in to participate in the conversation
Ecko / c4.social

Creating magic through evolution of the Fediverse. Running Ecko, a community-driven fork of Mastodon managed using the Collective Code Construction Contract (C4) by the Magic Stone Community. C4 is a protocol for asynchronous, non-blocking, distributed, problem-focused software development.