place meeting minutes on "draft-minutes" branch

[bblfish]

On Committing the Meeting Minutes

Here is the proposal:

1. Push minutes to the draft-minutes branch of relevant repository immediately after the call.
2. Improvements to the minutes MUST be PRs (can be done by editing the content on github)
3. After approval of minutes in next neeting, press github "Merge Pull Request" button.

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]

I moved it to discussions, as I want to have a place for the basic counter proposal to be discussed.

[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.

[bblfish]

Here is the Proposal made by @csarven on in PR 319:

1. Minutes state publication status. Initially set to "Draft".
2. Push minutes to the main branch of relevant repository.
3. Announce minutes URL.
4. Improvements to the minutes can be PR'd.
5. Approve minutes in a future meeting. Change minute's publication status to "Published". Merge minutes in PR if there is one, otherwise update the main branch.

The proposal here, which is what we have been doing for the past year differs from the above in

1. Not requiring to set "draft publication status to draft" as that is indicated by the branch on which the document is located
2. Push minutes to draft-minutes branch instead of main which
   • avoids problems of having to rewrite the history of main in case sensitive information gets published there
   • allows one to use the github PR notification system, which makes the new meeting minutes visible to all
3. there is no need to "announce meeting URL" as that is done by github automatically
4. same PR improvement process
5. no need to edit the content on main to change the text "Draft" to "Approved" and commit that. In this proposal all that needs to be done is to click the button "commit".

[bblfish]

I tried the idea of a draft-minutes branch on the Web Access Control Panels latest meeting minutes. You can see them here:
https://github.com/solid/authorization-panel/blob/draft-minutes/meetings/2021-10-13.md

The nice thing is that at the top there is a button showing clearly that this is the draft-minutes branch. One can then look to the final version by switching that pull-down to the main branch. All very user-friendly.