On Sun, Jul 16, 2023 at 12:07 AM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 16-Jul-23 15:50, Phillip Hallam-Baker wrote:
> Why is attending biweekly con calls exclusionary?
It depends where one lives and whether one has a full-time occupation. But really the point isn't there, it's whether the result of such calls (which de facto are design team meetings, not WG sessions) is brought back to a genuine WG plenary, electronically or in person, for an effective debate.
I'd probably be more comfortable if these meetings were pitched as open design team meetings; that would make things clearer.
I am not sure how an interim which anyone can attend without expense is less 'genuine' than a plenary WG meeting, whatever that is, presumably one at an IETF. I find meetings at IETF week to be highly exclusionary because regrettably, there is so far only one of me and I can only attend one meeting at a time.
As I see it, we have two different tools, asynchronous and synchronous communication. Raising issues and disposing of non-contentious issues is best dealt with via asynchronous approaches. Synchronous tools are best for presentations introducing new concepts and for working the contentious issues. The point being that there are inevitably points of contention when different paths have different tradeoffs.
I am not a fan of repurposing github as an issue tracking tool, I find Git to be a typical product of the UNIX culture of 'screw anyone who doesn't want to learn our arcane spells the fact we can master this shows have very very clever we are'. It is bad enough having to suffer it for source control but at least then the stupidity can be hidden by crafting some shell scripts. Nor am I a fan of Discord/Slack, a tool which appears to me to be the exact worst way to interact with other people: A constant interruption of comments that are immediately forgotten.
The Web, WebRTC conferencing tools and an issue tracker/discussion system are sufficient for me.
But the idea of building a working group process around an issue tracing tool is certainly sound and that issue tracker should ideally be built around annotations to the documents being considered by the WG.
So in this model the process would be:
* Working group starts, people make presentations in a synchronous forum showing their ideas for what the problem is and how the WG should approach it. The synchronous part being interactive discussion following each presentation.
* Documents are adopted, people make comments on the documents as annotations 'this part unclear', 'typo', 'this is not going to work', these become issues, they can also create issues that are not linked to a specific document.
* Straightforward issues are disposed of by the document editor, more complex issues lead to further discussion.
* Chairs select issues that are ripe for discussion at regular WG virtual meetings. The timing of such meetings being chosen to ensure the principal stakeholders on the issue as demonstrated by the prior discussion.
* When the IETF meets in plenary, the WG spends the time explaining what they are doing to the rest of the IETF community and working on cross-WG and cross-area issues.
