Re: November CG call - postponed one week (now Nov 8)

On Fri, Nov 1, 2024 at 6:42 PM Lisa Dusseault <lisa@dtinit.org> wrote:

> Early feedback even though we'll discuss next week - especially because
> the 1st point is all about readiness for next week
>
> 1.  The proposed CG charter at
> https://github.com/swicg/potential-charters/blob/main/CGCharter-1727386911.html
> is fine as far as it goes, but the scope section is still "TBD: describe
> topics that are in scope..." nor do I see where out-of-scope topics are
> actually listed, nor do I see any report topics that would be in scope
> (just that specifications on all topics are out of scope).  Is this
> something we could iterate on before the next meeting? Otherwise I don't
> think we'll be ready to adopt it, just discuss the parts that are there.
>

It's not ratifiable until all those TBDs and TODOs are PR'd in. And the
best (but also worst) part is, anyone reading this can open a PR, big or
small! None will get merged before the meeting but opening one, commenting
on someone else, change-requesting someone else's, or even counter-opening
a competing PR (that names the PR it wants to compete with) are all
super-helpful!


> 2.  I'm still thinking about the incubation/staging process.  It's got a
> lot of good stuff but there's something about the scale of "proposal" and
> "problem space" that got me concerned.  I'd love it if the intent of what
> scale of things this process is intended to apply for was clearer in the
> doc even if it's not normative and not perfect.
>

Me too!

> Is a *proposal* intended to be "a whole feature document" and the *problem
> space* is "why do we want a whole new feature" ?
>
That's how I meant them, but open to more detailed, capacious, or
constrained definitions, too. Try me!

To give an example at the probably-ridiculous other extreme, does a
> *proposal* include "I propose we should decide in ActivityPub what
> servers do when they receive a Move for an actor that has supposedly
> already moved"
>
That sounds way too in the weeds to be a whole proposal-- a better CG
proposal IMHO might be "harmonize Move behavior on an
opt-in/platform-specific basis" or "Harden/Iterate FEP-73cd as a
Portability TF report".


> and does *problem space* include "The problem space here is that
> ActivityPub servers behave differently when receiving conflicting Moves"?
>
I think that example would be _part of_ the problemspace of either better
proposals, definitely.  Maybe a broader problem space would be "Migration
User Stories and UX Expectations around Migration"?

Thanks for these examples, btw, it's really helpful for aligning
expectations and describing them better in the text of the doc.  Again,
anyone can open the PR, not just us two-- the best PR that gets us to
consensus fastest might actually be from someone reading this with flared
nostrils right now!


>    I think the authors have the incubation process in mind more for new
> features and new whole-ass specs, but when first I read it, my brain was
> thinking about all levels of changes proposed from tiny modifications of
> mature specs, on up the scale. Maybe this was obvious to folks who've used
> this incubation process elsewhere?
>
I actually forked this from another W3C process document specifically
scoped to incubations of new features on an extremely stable/in-prod,
load-bearing, bajillion-dollar-a-year protocol, so figuring out where
"ongoing work" and iterative, gap-closing, tidying-up, or maintenance work
fits in is... another TBD awaiting PR.  I was mostly thinking about an
iterative process where prototyping and incubation leads to tire-kicking
BEFORE any motions to pour cement can be entertained for new
features/whole-ass-specs-- but "maintenance work" (on already-implemented
stuff) feels like it's already starting on 3rd base, and any two
implementers of a given feature can signal they want
addenda/gap-closing/technically-normative-but-nonbreaking changes, right?
Idunno just spitballing here, mostly in the hopes that someone's nostrils
flare enough to open a PR...


> 3. I think
> https://github.com/swicg/potential-charters/blob/main/ap-maintenance-wg-charter.html
> is ready for us to talk about adopting, and I like it.
>
Nice! If anyone's nostrils are flaring about this one in an email-way and
not a github-way, maybe change the subject line so that it forks a new
thread?


>
> Lisa
>
>
> On Thu, Oct 31, 2024 at 12:12 PM Dmitri Zagidulin <dzagidulin@gmail.com>
> wrote:
>
>> Hi all,
>>
>> Apologies for short notice, but I'd like to postpone the monthly
>> SocialWeb CG community call for one week, to be now on November 8, 2024,
>> instead.
>>
>> Partly for high holiday reasons :) but mostly to give the group more time
>> to engage with the potential charter documents and PRs over in
>> https://github.com/swicg/potential-charters
>>
>> Specifically, during the November call, we'd like to discuss:
>>
>> 1. Adopting a CG Charter (current proposed version:
>> https://github.com/swicg/potential-charters/blob/main/CGCharter-1727386911.html
>> )
>> 2. Adopting an Incubation / Staging process (currently at
>> https://github.com/swicg/potential-charters/blob/main/stage-process.md )
>> 3. Discuss Working Group charter options
>>    - option 1: Focused AP+AS2 1.1 WG (current proposed charter at
>> https://github.com/swicg/potential-charters/blob/main/ap-maintenance-wg-charter.html
>> )
>>    - option 2: Wider SocialWeb WG, which includes AP+AS2, but also all
>> the other specs produced by the original WG.
>>
>> So, everybody has an extra week to read the proposals, make PRs, open
>> issues, and discuss here on the list!
>>
>>
>> 3.
>>
>