place meeting minutes on "draft-minutes" branch

[bblfish]

On Weekly Meetings

Details

For the whole of 2021 the panel Meeting Notes have been added as a Pull Request on a (temporary) branch, which could then be improved upon before pushing it in the next meeting to the main branch after a quick question to the group.

@csarven unilaterally changed the process for the 2021-09-29 meeting minutes, giving a number of reasons. I take it that the essential reason is:

• people can't immediately refer to the minutes reliably, as the branches were unique to each PR and got deleted after commit.

On the other hand, committing without review is going against a basic principle of version control: don't commit to main (aka master) without review. By pushing directly to main it may not be clear that the minutes have not been reviewed. It is established W3C policy to

1. automatically publish the minutes to a location that is well understood to be the non-edited, perhaps erroneous, attempt to capture the meeting notes. An example are these LDP IRC logs
2. in the meeting ask if there are any objections to publishing the minutes from the previous meeting, after they have gone through some formatting and other correction. The previous IRC logs show the group engaging in that by approving the minutes from 2015-06-15.

These problems can be resolved by having a "draft-minutes" branch, that is never deleted and to which the the new minutes are first pushed. This has the advantages of:

1. continuing the process that has been successful for us this year
2. making it clear that the minutes have not yet been approved to anyone coming across them,
3. allow people to immediately refer to the published meeting notes on the "draft-minutes" branch, with a URL that will keep working over time
4. making it easy for those who participated to fill in missing pieces by making a PR to the "draft-minutes" branch - we have had great contributions from @TallTed this year on this,
5. gives the process of asking for minute approval an actionable process: clicking the merge button

Note: publishing to a "draft-minutes" branch is no more complicated than publishing to main, and clicking a "merge" button is something that can easily be done in each meeting.

Acceptance criteria

• counter proposals should be made, if any
• vote on this in meeting in combination with any other proposal that meets Solid community guidelines

[csarven]

solid/specification#319 is a proposal for the CG as a whole. It takes concerns raised here and elsewhere into account. I suggest that we (i.e., the panel) adopts what's agreed there.

[elf-pavlik]

I think we should close this issue in favor of solid/specification#319 since it's more about a general process rather than something AuthZ specific.

[bblfish]

The following argument put forward by @acoburn on gitter, October 8, 2021 6:49 PM is that it is easy to revert using.

> git revert <commit>

The same idea has found its way in the discussion on the PR. It is true that git revert is not problematic from the point of view of git, as it undoes a change by applying a new one undoing the previous one. The history of the previous changes therefore always remain available in the history. A URL pointing to the original precise version (the permalink) of the commit will continue to work.

BUT, this is no good for sensitive information that may have found its way into a commit for exactly those reasons. Because git revert does not remove them from the history and the permalink to the original version will continue to work.

In order to actually remove sensitive information one has to change the history of the branch. There is a whole chapter in the git book on Rewriting History. This states right at the top that it is fine to make changes locally, because nobody is referring to your history, but it is a different story when you go public. Here is a warning about this from the git-rebase.io homepage:

A word of caution: changing the history of public, shared, or stable branches is generally advised against. Editing the history of feature branches and personal forks is fine, and editing commits that you haven't pushed yet is always okay. Use git push -f to force push your changes to a personal fork or feature branch after editing your commits.

If you rebase the main branch any change to the history is going to change the hashes of all commits, leading to potentially a lot of problems to anyone making changes to the branch and wanting to commit with the old history.