One branch for development, one for representing consensus.

[stasm]

Context: #230 (review)

In the past, the WG would only merge into main the outcomes of discussions which resulted in consensus. This model has worked well for defining the 'soft' artifacts: the goals, the design principles, the requirements, etc. At the same time I think it doesn't lend itself well to the more iterative nature of the development work that lies ahead of us.

As we start working on concrete implementation artifacts, like the spec wording, the data model definition, and the EBNF grammar, I'd like to propose a change in the process of reviewing and approving PRs to make it more suitable for discussing such artifacts.

Even a minimal implementation must sometimes make some assumptions to be complete from the formal point of view (so that it can compile). It would be helpful to streamline discussions by allowing these assumptions to be merged into the repo without them becoming explicit points of consensus, leaving room for a discussion later.

I'd like to suggest that we create a head branch (or develop) that would sit somewhere between experiments (where anyone can commit anything) and main (which represents the consensus of the WG). PRs to the head branch would require review from other members of the group before they are merged, with the understanding that some details or even larger parts of the implementation may need to re-worked in the future. Periodically, when we reach a major milestone and we all agree, the head branch can be merged into main.

This way, we can spread our work over multiple PRs and take advantage of GitHub features that are commonly used in development: PR discussions, assignments, milestones, etc.

[echeran]

I think I understand the gist of the idea, but compared to our existing experiments branch, this idea seems like a difference without a distinction. Last year, we were using experiments to stage data model proposals, and PRs were still used to communicate changes and solicit feedback (examples: 1, 2). The latest update to experiments is a couple of months ago, it seems.

If we continue to use experiments as we have been, we have one less place to look for our past & present work. I don't know how a new branch differentiates itself technologically in a way that moves the needle because you still depend on the human stuff -- agreed upon conventions & processes, which in turns requires a shared understanding, good communication, and adherence through consistency & collective due diligence -- which is true either way.

[stasm]

compared to our existing experiments branch, this idea seems like a difference without a distinction

The key difference in what I'm proposing is that the new develop branch have the same branch protection rules set up as main has. OTOH, experiments would continue as a free-for-all branch.

While it's true that the is a precedent in creating PRs against the experiments branch, I think you're right in assessing that they were used to (a) communicate changes and (b) solicit feedback. Both of these purposes were voluntary and optional – there's no notion of an (c) explicit review and approval on the experiments branch. There were also many direct pushes to experiments which didn't result in PRs.

With develop, I'd like all changes to go through PRs and be reviewed (LGTM'ed), but allow for some parts of what's merged to be recognized as incomplete and requiring further work. To sum up:

• develop – an unstable trunk branch, where LGTM'ed work in progress lands,
• main - a stable release branch, which represents consensus.