Using GitHub to conduct CfC

[plehegar]

Using 👍 or 👎 on CfC in GitHub can be changed after the decision was recorded by the Chair. We need a way to maintain the status of support (or lack of support) at the time of the Chair decision. For example, https://github.com/w3c/html-aria/issues/326 can still gather support. We should provide guidance to Chairs on how to avoid this in GitHub issues.

cc @swickr

[plehegar]

cc @dontcallmedom in case he has a good idea :)

[dontcallmedom]

The cumbersome manual way would be to have the chairs copy the list of reactions as a comment once the CfC concludes.

I would guess that creating a github bot to automate some or all of that shouldn't be hard - reactions are exposed in the github API (at least in v4).

[rigow]

This is an obvious blockchain application usecase (W3C can have a root key if we want to spare some CO2). So the question is rather how to export the tokens at the time of vote. This could be as simple as a timestamped screenshot of a github page.

[LJWatson]

It would be feasible to record the numerical results in the message that closes the CFC (for example, 10 expressions of support and no objections), take a screenshot to capture the results and upload it to the issue, then lock the issue against further editing.

It wouldn't entirely prevent the possibility of things being changed, but it would mean there would be a "paper" trail if something was changed.

The only time this might get cumbersome for chairs, is if the CFC garners a lot of engagement. For most WebApps CFC there are relatively few responses, but if a WG like AG were to use Github for CFC, I can imagine the figures might well be in the 30+ range at times, which could be irksome to count.

[dontcallmedom]

my suggestion for paper trail would be to copy the results of the reactions including the github names of the CfC participants (which github includes in the aria-label and as a tooltip on the summary of reactions) - that also means the people counted in the CfC get notified (which helps with accountability).

But yeah, having a bot to do it would avoid both lots of irksome manual work and risks for mistakes in copying the information (which isn't easily copyable from the github UI)

[nigelmegitt]

My suggestion here is that a simple 👎🏻 is not a valid objection to a CfC in itself: it needs to be accompanied by some written response (could be a scribed verbal response), which would inherently have a date-time. As a Chair I would expect as a minimum:

• description of the problem
• rationale for the objection
• proposal for resolution of the objection, if possible

To log the state of the CfC at the time that a Chair declares consensus, perhaps it is adequate merely to indicate the number of supporting statements (e.g. how many 👍🏻 s) and if the Chair has decided to proceed with the Decision while any objections are unresolved, and if so, how many unresolved objections there are.

If, later, the number of 👍🏻 s changes, or new objections are raised, then the Chair's statement of the CfC will not match the GitHub issue reactions, but... so what?

[plehegar]

@nigelmegitt If the record was lost, the Chair decision may look as irrational.

We could provide a tool to help taking a "screenshot" for the responders (including their github names). To help with the problem of finding the tool (let alone knowing that it exists...), we could also provide a GitHub template for Chairs to start a CfC in a GitHub.

[nigelmegitt]

@nigelmegitt If the record was lost, the Chair decision may look as irrational.

I'm suggesting that the Chair decision includes the record of the status as it was when the decision was made.

We could provide a tool to help taking a "screenshot" for the responders (including their github names). To help with the problem of finding the tool (let alone knowing that it exists...), we could also provide a GitHub template for Chairs to start a CfC in a GitHub.

Interesting - I'd certainly be happy to try that out.

[plehegar]

I just did a quick attempt for a tool that snapshot reactions: https://www.w3.org/2023/04/cfc-snapshot.html

You can try it on issues, such as:

• https://github.com/w3c/badging/issues/99
• https://github.com/w3c/html-aria/issues/326

[dontcallmedom]

Trying it on https://github.com/w3c/badging/issues/99, it shows the "hooray"s on the last comment (the one announcing the CfC passes), where I would expect it to show the "+1" on the body of the issue. Is this the behavior you intended?

[nigelmegitt]

@plehegar in TTWG we consider pull requests as CfCs, not issues. And we count PR review "approvals" as 👍🏻 and "request changes" as 👎🏻 rather than reactions.

One of the problems with counting reactions to individual comments (on issues or pulls) is that it misses response posts that include those same reactions, maybe accompanied by some explanatory text.

[plehegar]

Trying it on w3c/badging#99, it shows the "hooray"s on the last comment (the one announcing the CfC passes), where I would expect it to show the "+1" on the body of the issue. Is this the behavior you intended?

yes. If you try on the second example I gave, you'll notice that some of the +1 were on the second comment. Since this is a snapshot meant to be copy/paste, the hooray on the chair decision would not be there. And the chairs can use their judgment when doing the copy/paste.

[plehegar]

@plehegar in TTWG we consider pull requests as CfCs, not issues. And we count PR review "approvals" as 👍🏻 and "request changes" as 👎🏻 rather than reactions.

One of the problems with counting reactions to individual comments (on issues or pulls) is that it misses response posts that include those same reactions, maybe accompanied by some explanatory text.

This tells me that different groups will use different ways to record the +1. I should stop being surprised by that :) I can include a way to count the +1 both in reactions and comments.

[plehegar]

@nigelmegitt , can you point me to an example of a pull request that includes a CfC?