Re: DRAFT agenda for the next Process Call, September 12th 7am PDT (note time)

> On Sep 13, 2018, at 10:05, Jeff Jaffe <jeff@w3.org> wrote:
> 
> 
> 
> On 9/12/2018 7:50 PM, David Singer wrote:
>> Looking at the Diff
>> <https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2018%2FProcess-20180201%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2F%23contributor-license>
>> 
>> I am concerned that we should not fail to adopt these plausible improvements, because we didn’t do something larger. We can always do the larger thing when it’s ready; why should we not improve as we can?  Does every update have to be significant?
> 
> I respect the pov that we should go forward with what we have.
> 
> It's just that my pov is that we need to force ourselves to get more done because there is so much left to do.  That is much of what I was saying below.  I fear that if we content with small quantity of changes per year we will never get to the big stuff.
> 
> Certainly if there is a consensus to move forward with what we have, I would not block it.

I'd like to respond on 3 different aspects.

~~ Part 1: publish or not ~~

These are not a lot of changes, but overall, I think we're better with them than without.

The one worry I have is that the most substantial change is about the number of seats in an election, and that bringing this to the AC with the other aspects of elections still being unresolved (or even without a proposal on how to resolve) is poor planning and may blow up in our faces.

~~ Part 2: productivity ~~

Regardless, the list is indeed very short, and I do agree we should try and get more done. I hope that my addition as a co-editor will help move that needle slightly, but I suspect that won't be sufficient, and we need to give serious thoughts about our work-mode. Currently not much gets done other than in the 48h or so before a conf call.

Conf calls are useful to unlock progress on various topics, but we should not need to wait for a conf call to approve uncontroversial changes, and consequently we should not wait for just before a conf call to express or opinion on whether changes are controversial or not.

For the sake of increasing the throughput, I suggest we change the work mode to:

* The editors are empowered to make markup fixes, spelling & typo fixes, date updates, copyright year updates, change section updates, and the like without waiting for resolutions. Using Pull Requests for such changes is of course allowed if feedback is desired, but not required.

* Participants are expected to make pull requests and to comment at pull requests continuously, without waiting for the conf call

* The chair should assess the consensus on Pull Requests & issues continuously, and Resolve for or against changes without having to waiting for the call. For trivial/editorial issues, this can be done in an ad-hoc way, for substantial issues, a CfC should be used

* The call should be used for 2 things:
  - Go through (in a priority order determined by the chair) individual issues that have been marked as someone as "Agenda+"  because they're trying to get closure (or feedback, or input) on something where they feel a voice discussion would help. Resolutions taken during a call don't need to go through an asynchronous CfC and can immediately be used by the editors to make changes. (That doesn't prevent anyone from reopening / opening a new issue later if they disagree.)
  - For the Chair to admonish people about following up on things we've said were priorities

~~ Part 3: Large Changes & Evergreen ~~

I also agree that when we have potential major changes on the horizon, we should make sure they don't get pushed down the todo list by easier but less consequential topics. But that doesn't mean that making major changes or additions should be a goal in itself. "We should not do this" is a perfectly acceptable conclusion to reach on major topics.

Evergreen is a good example of that to me. Clearly it is a large topic. Clearly, saying this is important and then not looking at it is not good, so we should look at it, and I am willing to participate in a taskforce that tries to get to the bottom of it. But it doesn't follow that we necessarily ought to be adding it to the process. Maybe we should, but maybe it's a bad idea and we ought to resolve to reject it.


—Florian

Received on Thursday, 13 September 2018 07:34:41 UTC