Re: Adjustments to our work mode - please read

["Eliot Lear (elear)" <[e-mail]>]

Mark,



Eliot
> On Oct 5, 2015, at 7:14 PM, Mark Nottingham <[e-mail]> wrote:
> 
> Eliot,
> 
>> On 5 Oct 2015, at 10:53 pm, Eliot Lear (elear) <[e-mail]> wrote:
>> 
>> Mark,
>> 
>> On the whole I believe this is a reasonable experiment.
> 
> Good.

I mean it.  It's a fine thing to try. But you can't break transparency. See below. 

> 
>> First, you are a chair and not a king.
> 
> Indeed; if I were a king, I wouldn't have to talk to the AD about it. There's also probably be a lot more "off with his/her head" around here...

Let's not get ahead of ourselves. 

> 
> 
>> You should have proposed this to the group before acting.  Do other chairs get to pick and choose their rules?  
> 
> The responsibilities and authorities of a chair regarding process and communication seem very well-documented here:
> http://tools.ietf.org/html/rfc2418#section-6.1
> 

Yes, well. Please read the REST of that document.  It is speckled with references to how EMail should be used and in what circumstances. Want to vary from that?  Fine.  But document what you're doing. 

> 
>> Had you consulted the group first, someone might have asked the question about how those coming into the group anew would understand the process. Others might have asked about whether GitHub is sufficient for archival purposes.  Others might have asked how easy it would be to manage two parallel discussions on the same issue.
> 
> You're giving me a lot of hypotheticals, Eliot. If you have actual questions, I'm happy to answer them.


New people coming into the group is a hypothetical, is it?  Having two parallel discussions is hypothetical?  But the point is really that you didn't consult the group and should have done. This is not a small change, though probably a useful one.

> 
> 
>> Anyway, what I ask at this point is four things:
>> 
>> 1.  The charter of the group should indicate the procedures being used. 
>> 
>> 2. Those procedures should be documented in a draft.
> 
> Nothing in the IETF process that I can see requires such a level of bureaucracy. While I can see the point of doing so if this work mode "sticks" over time, requiring us to do so just to perform an experiment is busy work.  
> 

Because sticking your email in a draft and pointing at it is so hard.   Come on.

Transparency requires that people be able to know what the rules are. Because you're using an additional communication path that is not documented elsewhere it's on you to ensure people aren't surprised and that people know when issues are going to be closed and what the resolution is.  That makes a result stronger.  

Pragmatically how do you expect someone coming into this wg from another wg or a new participant  to understand how things work?  And what if you change things further?  Shall Mark's Rules be a collection of emails that must be parsed and diffed? 

> 
>> 3.  Before you close an issue in GitHub, you should give fair warning on *this* list with a pointer.
> 
> As mentioned, issues can always be reopened, and will be summarised for each draft as we've often done in the past. In practice, I suspect that contentious (or potentially contentious) issues will be at least canvassed here before they're closed anyway

To be clear: that document you quoted expects two types of communication:  mailing lists and meetings. You are adding a new type. That is fine, but there are a lot of words around how mailing lists get to review other decisions.

> 
> 
>> 4.   Finally, you have repeatedly and needlessly used derogatory language toward those who have worked hard for *this* organization. I think you owe that group an apology. 
> 
> You've lost me, Eliot. How have I done so? Have I offended *you*, or are you just concerned on behalf of others?

I'd like to know who you think you're talking about when you use the term "professional" standards people,  juxtaposed against users and developers.    It sounds to me that you are referring to those who have done a lot of work in and for this organization-  as if they aren't developers or users or should have less voice in the process because they've been around.  Yes I'm in that class. It was wrong of you to put it in those terms. 

I imagine what one would politely say is that the process is not inviting to the class of developers we need for this WG to succeed, and that they are more comfortable using GitHub.  

And as I wrote above that's fine. Just document what you're doing and give those using email notice when you are going to make a decision.  How hard can that be?


Eliot