W3C Solid Community Group Meeting Guidelines #319
Conversation
There was a problem hiding this comment.
The meeting minutes should be published to a "draft-minutes" branch as explained below and in detail on this issue solid/authorization-panel#267
meetings/README.md
Outdated
| Steps to publishing minutes: | ||
|
|
||
| 1. Minutes state publication status. Initially set to "Draft". | ||
| 2. Push minutes to the main branch of relevant repository. |
There was a problem hiding this comment.
Minutes should not be pushed to main, as
- as a general policy one should not push to the main branch without review
- it can give the false impression that what was written down was agreed on
- if private or sensitive information is mistakenly introduced it cannot be removed without breaking the
mainbranch (one should never rebase the main branch!) .git revert <commit>would still leave the information in the history
This is easy to fix though. I propose instead to place the minutes immediately on long lived "draft-minutes" branch". See the detailed argument solid/authorization-panel#267
There was a problem hiding this comment.
as a general policy one should not push to the main branch without review
it can give the false impression that what was written down was agreed on
Publication "status" clarifies that. What's initially committed is "draft". That's not a false impression of anything. Meeting minutes exist as is. The publication steps and the guidelines as a whole describes what's "draft" and "published".
The document is self-descriptive.
There was a problem hiding this comment.
So in order to move from "draft" to "published" the editor has to create a PR with that change, which is committed on the main branch during the meeting? In that case publishing to "draft-minutes" (as proposed here) is the obvious and easy thing to do and pretty much what the authorization panel has done for the past 9 months.
Also you don't address the major problem of not being able to remove sensitive information from the main branch.
There was a problem hiding this comment.
So in order to move from "draft" to "published" the editor has to create a PR with that change
No, the steps include:
Merge minutes in PR if there is one, otherwise update the main branch.
As for:
which is committed on the main branch during the meeting?
No. Any time / "soon after".
In that case publishing to "draft-minutes" (as proposed here) is the obvious and easy thing to do and pretty much what the authorization panel has done for the past 9 months.
- This is for all kinds of meetings in the CG.
- Several approaches have worked in the CG.
- This PR is not about adopting the "draft-minutes" proposal that is ACTIONed (but objected) in the authorization-panel.
I did my best to take all input into account in this PR.
Also you don't address the major problem of not being able to remove sensitive information from the main branch.
That's covered by checks along the lines of:
No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
Stops transcribing on speaker's request.
Requests assistance to improve transcription, e.g., mark text that needs correction or improvement, ask speaker or moderator for clarification.
May correct or improve fields marked by scribes during meeting.
If "sensitive information" is out there, the branch is irrelevant.
There was a problem hiding this comment.
If "sensitive information" is out there, the branch is irrelevant.
No: sensitive information can be removed from other branches with a rebase with a lot less problems. True you can never completely unsay something but that does not mean it has to be kept published forever.
Also: it happens more often than one thinks, that one does not realise the consequences of saying something. Given information that is available to others some information may have more impact than one could know.
So for reasons relating to sensitive information, I am -1 on your proposal. But luckily it's only a minor change to fix it :-)
This is for all kinds of meetings in the CG
What you are doing then is requiring everyone in all the CGs to adopt a bad practice of committing to main, which brings no advantage.
What advantage do you see in your proposal over the simpler one explained above and detailed here, that does not have the problem of writing to main?
solid/authorization-panel#267
There was a problem hiding this comment.
No: sensitive information can be removed from other branches with a rebase with a lot less problems.
Keeping in mind that the sensitive information is first shared in a public meeting, and if after all of the reasonable measures that can be taken in this guideline to reduce the chances of sensitive information leaking out, and still if a public branch on GitHub can't be reverted or the whole repository can't be rewritten, then I'd question the significance of those problems.
There is nothing further to discuss about "sensitive information" that's anything above and beyond what any other W3C group or GitHub project has to work with on a daily basis. Trivial to create snapshots at the Internet Archive on any activity. If there are significantly better processes or tools in place that can be used to improve the current situation, we can use them provided group agreement.
What you are doing then is requiring everyone in all the CGs to adopt a bad practice of committing to main, which brings no advantage.
Not all commits are PR'd in the CG. There is no policy or process that covers all commits. I generally agree with you on the importance of peer reviews but I do not find approvals to be restricted to a particular branch or type of issue.
What advantage do you see in your proposal over the simpler one explained above and detailed here, that does not have the problem of writing to main?
If I respond to that question, do I have to accept the other proposal to be "simpler" and "does not have the problem of writing to main"?
The proposal uses only one (persistent) meeting URL.
If it is possible to have something like a symlink from latest meeting.md in main to meeting.md in another branch, and have main's URL be usable, that'd be reasonable.
There was a problem hiding this comment.
The proposal uses only one (persistent) meeting URL.
Are we running out of URLs now? The easy answer is the following:
after verifying that there are no objections to the previous weeks draft-minutes and committing them, the scribe enters the URL of the just published minutes. So every minutes document contains a permalink to the previous sessions' minutes.
There is nothing further to discuss about "sensitive information"
The easy way out of any problem is to deny the problem.
There was a problem hiding this comment.
The proposal uses only one (persistent) meeting URL.
Are we running out of URLs now?
I don't understand the question or point.
The publication status indicates important information. Information that need not be derived from the URL or have an understanding of a particular service provider or software or specific knowledge.
In the PR's proposal, the reader can always get the latest state from a single URL (via main branch). In the draft-minutes branch proposal, there is no indicator about its state. Even if the consumer understand the URL tied to draft-minutes branch, it will not know whether it is approved or disapproved, and when. They will have to follow-up in some way to understand the latest state of the minutes.
If the draft-minutes proposal includes the publication status, then the number of commits from draft and published remains the same. That'd still be two URLs out there (of draft-minutes and main branches) instead of just one URL (main branch as per this PR).
As mentioned, if the symlink-like approach is possible, we could do the draft-minutes branch/PR, but it will still need the publication status.
There was a problem hiding this comment.
I think we're overthinking this. Merging minutes to main is totally fine.
meetings/README.md
Outdated
| 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. |
There was a problem hiding this comment.
3, and 4 are great. Note that by publishing to a long lived "draft-minutes" branch all URLs will continue to be valid over time.
But what is there to approve in 5 if the minutes are already on main? I fear that since there is nothing to do, that step will be forgotten.
Adding the minutes to a "draft-minutes" branch has the advantage of creating a technical requirement for the group to be asked if nobody has an objection, which is very important to create what is known as a common understanding, a.k.a. common knowledge.
So I suggest to add a step:
- 5a commit "draft-minutes" branch to
mainafter asking if there are any objection.
There was a problem hiding this comment.
But what is there to approve in 5 if the minutes are already on main? I fear that since there is nothing to do, that step will be forgotten.
It is an editorial process. A state or condition that a document may have that relates to the publication of such document. Changing from "draft" to "published" requires group agreement.
There was a problem hiding this comment.
Changing from "draft" to "published" requires group agreement.
having a "draft-minutes" branch makes this a very simple process. No need to edit the document and change "draft" to "Published" after the meeting.
You get the same effect by by clicking the "commit" button in the meeting. That copies the minute from the "draft-minutes" branch to the "main" branch automatically, and simultaneously makes both draft and final version synchronised.
So this requires one less step of the panel, and is therefore more likely to be completed successfully.
There was a problem hiding this comment.
So this requires one less step of the panel, and is therefore more likely to be completed successfully.
There are two commits in the proposal of this PR.
In the draft-minutes proposal, there is one i) commit that's ii) PR'd, and one merge action.
I don't know what's the best to measure and how we can determine success in a way that will help us reach consensus.
There was a problem hiding this comment.
The draft-minute proposal goes like this:
- place unedited minutes on
draft-minutesbranch within a hour after the call - accept PRs to the
draft-minutesbranch - In the next meeting ask if there are no objections to merge to
main - merge (click the merge button on GitHub)
In your proposal it is the same from 1-2 but change draft-minutes to main. Then
3. ask the panel if they have no objections with the material already on main.
4. after the panel the editor has to go and edit the previous meetings to change the status from Draft to Final and push that change. That is obviously not done as a PR, so conscientious members will have to check for themselves that the changes were made: all extra work that was not needed in the "draft-minutes" proposal, which we have been using for 10 months now.
Anyway, all of this does not even count the fact that the PR system is well known, is something that people can easily check when looking at the repository, notifies people of changes by sending e-mails, etc. etc...
There was a problem hiding this comment.
Guidelines on good scribing processes are welcome.
But that does not justify breaking a system that has engaged members of the Access Control Panel for the past year.
Furthermore it is just bad bad bad to push to main without oversight. Doing that can only lead to misunderstandings and reduce interest in participation.
The idea of these panels is to come to a rough consensus with working code, not act as a window dressing to make it look like there is consensus.
There was a problem hiding this comment.
Again:
This is for all kinds of meetings in the CG.
Several approaches have worked in the CG.
authorization-panel is not the only concern.. and in fact, some of the other panels still PR. That's fine. We're trying to improve the situation because while scribing is lagging we are collectively spending a lot of time on fixes. Some of those fixes... IMHO, take more time to create/approve than they're actually worth doing. There is much cognitive load that we can do without. So, perhaps what "worked" here is subjective.
Moreover, there is some interest from the CG that pushing directly will do. Okay, I'm responsible to putting that forward but if there is anything we can learn from it, people do want a smoother process. I've taken obviously taken your account on approving. Reminder that I have originally proposed that the agenda includes minute reviewing because the panels weren't doing it:
ReviewMinutes: Review/approve previous meeting minutes
https://gitter.im/solid/specification?at=600eda39ac653a0802df61f7
Good that at least that got picked up, right?
Furthermore it is just bad bad bad to push to main without oversight. Doing that can only lead to misunderstandings and reduce interest in participation.
Again, I agree to some extent. Depends on context. As an editor of some specs, I push to main when I consider the changes to be trivial, cosmetic, markup, basic editorial stuff that doesn't require everyone to wake up, chase the changes, reach consensus before merging. I make the call in good faith - which can be verified in commit history. I PR what needs actual reviews.
This is not to argue that "approving" minutes is trivial or insignificant. Instead, I see scribes as the responsible party to push that stuff in. We don't have the bandwidth to do diffs between the temporary document where we take the notes with the one that makes it into GitHub (doesn't matter what branch).
The idea of these panels is to come to a rough consensus with working code, not act as a window dressing to make it look like there is consensus.
Participation in good faith is key.
Edit: removed unnecessary disrespectful expressions
There was a problem hiding this comment.
I'm for keeping it simple until we have a strong reason to do otherwise. These are public proceedings, so I don't find the concern about sensitive information compelling, and there are ways to revert commits if necessary. Changes to submitted minutes can be PR'd when desired. At the moment I'm not aware of any significant controversy in our community over changes to minutes after the fact to improve accuracy of the record. Adding more steps feels like we would be solving a problem that we haven't experienced acutely.
There was a problem hiding this comment.
I'm for keeping it simple
+1 That is why I suggest we continue doing things as we have been doing them see draft-minutes branch proposal, which is simpler that what is proposed here since it does not require the final edit to change text in the minutes from "Draft" to "Final".
there are ways to revert commits if necessary
There are ways to revert that are ok for non-sensitive information. But no non-disruptive ways to revert for sensitive information. I explained this on the counter proposal here.
The two issues above are related: @csarven's proposal requires that the original raw minutes sent to main contain the text Draft at the top, because otherwise the content of the minutes on main may be thought to be final. Indeed, we have seen over the past year how many unclarities remain in the minutes, with sometimes text missing from the record, which can lead to serious misunderstanding of what someone has said.
So either one has to write the Draft stage clearly in main and then edit that for the final commit, or one publishes to a draft-minutes branch and simply commits that to main.
There was a problem hiding this comment.
Incomplete comparison.
The URL to the minutes on the draft-minutes branch would be analogous to https://www.w3.org/2015/06/29-ldp-minutes.html . Difference? The LDP URL states "- DRAFT -" in h1 right at the top!
The URL to the minutes on the main branch would be analogous to https://www.w3.org/2013/meeting/ldp/2015-06-15 . Difference? No difference. There is no "draft" because that's "published" (or "final").
Why would W3C go to great lengths to publish two URLs but also make sure that one is marked as "draft" and the other is not? Why do almost all specs include a publication status? Why do any document for that matter?
If the proposal you're putting forward omits publication status, that's fine. If "draft" status isn't a requirement, then the proposal in this PR need not include a step to update either. That'd be a useful comparison.
If having a PR is the main attraction, the branch it is on is not that important.
This comment has been minimized.
This comment has been minimized.
|
Since we publish directly to the final URL, what benefit gives us starting with Draft status and changing it later to Published? If we only allow one week for PRs with amendments we could call the final state Final, but I don't think we have to put such a strong restriction. If we leave it open to accept PRs after the first week I don't think we need status at all. When it comes to approving the minutes, one can always propose change via PR so this doesn't seem needed during the meeting. Recalling W3C IRC -> HTML RRSAgent I think it used to generate a summary of RESOLUTION and ACTION at the bottom. We could adopt something similar, and only bring up those two sections at the following meetings. We already semi-regularly bring up ACTIONS from the last meeting during the following up to review their completion. Having an extra section with a copy of all ACTIONS taken through the minutes can make it easier. Preferably scribe, besides pushing minutes to the repo could also create a pad from the template for next week and copy just the actions there. When it comes to RESOLUTIONS we could consider recommending an extra burden for the scribe to copy all the resolutions (without 👍 👀 👎 votes) into dedicated sections at the end of the minutes. This would make it easier for everyone to interested to keep track on them without and only read minutes if some RESOLUTION catches their interest. |
meetings/README.md
Outdated
| 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. |
There was a problem hiding this comment.
I'm for keeping it simple until we have a strong reason to do otherwise. These are public proceedings, so I don't find the concern about sensitive information compelling, and there are ways to revert commits if necessary. Changes to submitted minutes can be PR'd when desired. At the moment I'm not aware of any significant controversy in our community over changes to minutes after the fact to improve accuracy of the record. Adding more steps feels like we would be solving a problem that we haven't experienced acutely.
|
For reference, the counter proposal to the meeting minutes process described in this PR, is the following:
A step by step comparison to what is proposed in this PR is to be found in discussion 268. |
|
I'm not going to flag any strong opinions on this, but also since silence doesn't forward anything, I'll just share my general preference. My general preference is to use the mechanics available to us at the platform we happen to be using, and therefore, I like the direction proposed by @bblfish . |
|
Reasons behind the decisions are getting lost. Incomplete comparisons. Some of the things that's relevant:
It is not difficult to come up with workable solutions if considerations like the above have clear responses and there is unanimous or majority agreement. Clearly the assumptions and principles differ, and that's precisely why this PR exists, to have an actual process/guideline that we can use and improve. Besides that, I don't find the comparisons particularly meaningful. Arguing that x has worked for so long completely ignores the fact that it has also used up a lot of group time. Is that part of the base cost of running meetings and publishing minutes? Probably yes. It is worthwhile to not overlook the fact that some groups have also worked just fine without going through an explicit draft process.. for nearly a decade. Compare that to one panel's "9 months"! And, so the approach to push directly to main and improve later attempted to address that. But if the "requirement" is to get "approval" in a weekly meeting among those that are present in that particular meeting, then there is absolutely no point in talking about an approach that doesn't include that. Don't subscribe to some preferred requirements and then rule out the other solutions. They just have a different starting point. Having a draft branch still does not eliminate the issue on open PRs that may or may not be merged on a weekly basis - and we have data showing that. What's addressing that? Nothing is mentioned about that in the draft-minutes solution as if the problem just disappeared or didn't exist. Essentially it all comes back down to 1) quality of transcripts 2) maintaining good faith 3) maturity of the group. Not opposed to the solutions put forward, but we need to acknowledge why they all came forward and how they differ in their requirements and principles. Suggestion to compromise/revise the proposal in this PR: Create a PR (in whatever branch it is most suitable) immediately after meeting. I hope we can compromise and reach consensus. We've reached our monthly bikeshedding quota :) Jokes aside, we needed to have this discussion because we needed to improve current process/practice. So, that's important IMO.) |
So finally we come to your telling us what the problem you were hoping to solve was. Because until now I have never heard anyone bring this up. The process of people thinking through what was said in the meeting carefully, has been very helpful and has started bringing the Web Access Control Group to somewhat of a common understanding, which is what this whole process should be doing. It is the one place where some participation has been occurring. There are things to be improved, but writing to the
It terms of time savings I could easily argue that your (@csarven) insisting on proposing this push to |
Not news. I was quite clear a number of times in chats, PRs (including this one) about the time that goes into updating minutes. Let me know if you want me to fetch links and re-quote, again. Others not bringing up does not mean that the issue did not exist. People go with the flow, have different thresholds,.. It is not always obvious up front until attention is drawn to it. If you don't think threads of minute updating is an issue, then that should be acknowledged up front. I'm acknowledging that time can be put into updating but there should be a limit because there are other things to consider as well. See again the last suggestion I made. (You count GitHub triggering notifications for PR open/close as a plus, but do not acknowledge the cost / cognitive load on getting notifications for each update in your argument/calculation.)
Perhaps. We can't assign people to do stuff on a weekend, but it can be automated. I've mentioned several times now that the authorization-panel is not the only one that matter or even the places where any particular person is engaged in.
So let me get this straight. Cool. Who wants to volunteer? Until someone wants to assign themselves to write the code/docs around that, it is not worthwhile to consider. Perhaps in the future. We could also just go back to using W3C's stuff - which I'd be completely fine with. People want simplicity and very loudly bring up their discomfort with issues on updating publication status from "draft" to "published" - mind you that the thing totalling two commits - but somehow cool with throwing more requirements, wishlists into the mix and that's fine? (Again, the suggestion I made in the previous comment is making even more compromises.. and okay to go with PRs.)
You could argue but then I'll have to tell you to not read every other line, and consider the possibility that I am taking key considerations into account and facilitate consensus. You could argue but then I'll have to tell you to not read every other line, and consider the possibility that I am taking key considerations into account and facilitate consensus. I am responding to your concerns with the PR, as well as the proposal you're making with incomplete comparisons. That is not "insisting". If the ideas can be improved, adopt new concerns,... great. What do you think I've been trying to do this whole time?
|
|
@csarven's latest simplified proposal:
I don't see why the PR should be committed to The process I see should be the following simple process as I proposed in issue/discussion 268.
That is open, visible to all and simple, as it should be. It fosters what in epistemology is known as Common Knowledge (see Stanford Encyclopedia of Philosophy entry): that everybody knowing that everybody knows p. That is what is needed to move forward on consistent ACTIONS, etc. |
I brought it up since fiddling with status like "published draft" and "published final" doesn't really seem to contribute to getting things done in the panel. On another hand, having a pattern that strongly encourages that we all follow up on actions taken does help with GTD. I think 'approving' the raw minutes after everyone had a full week to PR what they would like to change is just an empty ceremony. I can see the point of raising objections on RESOLUTIONS from past meetings ASAP but that also can happen any time in the future if a strong reason comes up. The dedicated RESOLUTIONS section at the bottom might facilitate spotting it on the early side. As mentioned above reviewing ACTIONS from last week should help us with GTD. I'm happy to defer it and follow up with separate PRs for ACTIONS and RESOLUTIONS once we resolve this initial workflow here.
👍 I think we could all agree on that, it seems like an approach you have taken yesterday with solid/authentication-panel#196 |
|
Henry, Pavlik,
AFAIK, if the destination branch is main, the source is a different branch. Typically the one-off PR branches are deleted after merge, so why would the name matter? I don't care about bikeshedding the name or whether the draft-minutes is a persistent branch. The PR is updated as needed, and merged into the main branch only when "approved". There is no point in keeping a draft-minutes branch around as I see it. Keeping it around only exposes the URLs longer and if there is no publication status, it can cause confusion. Using only the main branch for the approved is sufficient.
Publication status is important. I've suggested publication status in context of using a single URL, getting the minutes out there immediately, and changing its status once approved.
Like.. a template? I'm not opposed to a section that's strictly listing those things. I just find the discussion about it to be a distraction in the PR of meeting guidelines. |
|
Just to be clear, besides the minutes publication steps, is everything else in the guideline reasonably okay to merge? Can we at least agree to that? |
|
I think it is worth repeating that these are guidelines for the CG. Panels are perhaps the most obvious place they can be useful, but I'm not sure if every meeting under the CG needs to follow.
Worth also mentioning that the Solid Team (which is not part of the Solid CG) doesn't have a process to review minutes either. (They've been posted to the CG wiki, but we may need to change that.) |
-1 Friday is different than Monday. Holidays also happen. Speaking at least for myself, I'm far less likely to review things on Saturday or Sunday or even in later hours of Friday. "One (or two) business days" might be agreeable, but I much prefer at least a week between a preliminary (draft) log and corresponding prettified minutes, and their approval. FWIW, historically, in meetings I've been involved with that used W3-based and/or provided and/or created tools --
I think a similar process should be followed in the Solid-related calls today. The git-tracks-and-retains-everything (where neither the old IRC log nor the RRSAgent-prettified minutes retained any record of changes) difference does hold some potential trouble in the rare instance of sensitive information being found in the log. I have no good suggestions for resolving that, and I don't think it's well resolved by any of the current proposals. Lastly, it's worth noting that charters of all W3-related groups (CG, WG, TAG, and otherwise) require the production and retention of such minutes, which are meant to provide any future reviewer with full context of decision making and other process (so any slidedecks, videos, or other materials are also meant to be retained alongside the minutes). |
|
I tried the idea of a This URL can easily be regenerated if someone accidentally deletes that branch, another nice feature. 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
|
meetings/template.md
Outdated
|
|
||
|
|
||
| ## Present | ||
| * [name](url) (moderator) | ||
| * [name](url) | ||
|
|
There was a problem hiding this comment.
| ## Regrets | |
| * [name](url) |
If we intend to use it for RSVP it seems to make sense to include this as well.
csarven
force-pushed
the
meeting-guidelines
branch
from
86650d7 to
449c759
Compare
|
As we currently have no consensus on meeting publication steps, I've decided to remove the section on "Steps to publishing minutes" in this PR. It is better to have this guideline in (merged) with the parts that we do have consensus on, FWIW. I acknowledge that we may need more experience/feedback on meeting publication steps, i.e., what works and what doesn't for different people and groups. We can incorporate that later on. Thanks all. |
Some notes below. Not required reading for the PR.
Using the W3C Process as guide, the recommendation is that the minutes of distributed meetings should be available after 48 hours. As far as I can tell from documentation related to scribing and minutes - and personal experience - groups come to an agreement about what's on record - how exactly they agree on the record is not specified. W3C groups use different approaches (and tools), e.g., minutes are shortly available after the meeting, draft minutes are generated, and approved by the group, and in other ways. I've pinged people as well as W3C (on IRC) for pointers and experiences but so far it seems that there is no formal process for agreeing to what has been minuted, and corrections are rare. Will share info once I know more.
Edit: The initial feedback that I got and reconfirmed:
CSS WG posts the text of the official minutes to their mailing list as is (single URL). They allow in-meeting corrections (on IRC). Members are invited to reply with corrections in a new thread, and apparently that rarely happens.
Credentials CG posts a copy of the text of official minutes to their mailing list and to a separate URL (for 8 years now), and apparently corrections were made only a few times (due to confidentiality reasons).
Minutes committed directly to the main branch takes the position that there is one URL for the minutes, scribed content is in sufficient quality and done in good faith, and allows corrections to be PR'd.
Corrections and missing information to the minutes are raised as PRs. Verifying changes to the minutes are done by the group. Relies on group's memory (and good faith) - no audio/video recordings for additional checks.
Concerns about prior group agreements are generally raised as a topic in meetings.
It'd be ideal to use only one URL to the minutes that's available shortly after the meeting. This has the same approach as what's commonly known as the "latest published version" in specs or "original resource" in Memento. It is useful to know the publication status of any documentation. Corrections are welcome and should be transparent. I do not ultimately what branch or whether there is a PR that a human/machine needs to merge.