Internet Engineering Task Force 103, 7 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF103-WUGH-20181107-1350

Description

WUGH meeting session at IETF103
2018/11/07 1350

https://datatracker.ietf.org/meeting/103/proceedings/

A

Let's give everyone another minute or two to figure out whether this is meeting one or meeting two.

A

But well yeah, but there's no signage outside. So oh.

A

B

The I'm sorry their signage.

A

Not in the obvious place.

A

Okay, let's get going so this is the working groups using github off. You can pronounce the acronym in almost any way that you want. There's woof-woof log wool, yeah I'm, sorry- and these are just the English ones- I mean I. Imagine that some of the folks from other countries can give us additional ones, but this is the second meeting of the bath. Our first meeting was a couple years ago. This is not a working group farming Boff.

A

If you are here because you were wondering you know you want to get in on the ground floor before horns, work and group- don't need to do that at all the here. Let me just flip us to the agenda, so we've got two presentations today, one from of a new draft which ELISA, Cooper and I have put together and Melissa will be giving that the second presentation is Martin Thompson from an old draft.

A

That is well expired, but was one of the things we talked about a lot at the last Boff meeting and then it's gonna be open mic and basically our idea for open mic is not just I wish. People would do this or that or I wish people wouldn't do this or that but more. What are the experiences in various working groups with using github? The idea here is not that you know github at least in the way, we're thinking.

A

Currently, it's not going to ever be required for working groups, never going to be prohibited, it's a tool that working groups can use and different working groups. We know- and this is I'm saying the same thing I said at the last Boff- some working groups use github radically differently than others, so this is a way of sharing experiences, hopefully mostly best practices. There are some worst practices or, like this working group is doing this and we decided we really want to stop doing it and do something else.

A

That's all very good fodder for the open mic. This is definitely an open mic whose intention is we want people to listen so that they can do better things and they're working. We have a minute acre. Thank you. David Lawrence. We have a jabber scribe, Thank You, Dam York. We've got a couple. People on me to go in case. They jump in I, guess I'll ask: does anyone want to bash the agenda, but I sort of assume anything that would be agenda bashing would just appear in open mic.

A

Thank you for Heather. When you got up I thought you were about to agenda bash, which would have made me have to type on slides a lot. So thank you, okay, Melissa. Why don't you start us off.

A

A

They're, a very full screen full screen.

C

So Paul and I put this together because it seemed thank you anyway.

C

So Paul and I put this draft together because it seemed like oh I know: I was getting a lot of questions from people who participate in working groups that haven't gone in as deeply on the github train and we're wondering about tooling support or naming conventions.

C

Like you know, what's the state of play with using github in IETF working groups and obviously there's a diversity of different practices out there among existing working groups, who do use github very heavily, but it was starting to seem like if we could adopt some uniform conventions and potentially tooling, to help make it easier for new working groups to start using github. But that might be a useful thing to do and also that the community might feel a little bit more comfortable with that.

C

Now that we've had more experience with it than we had at IETF 98. The last time we had this ball. So the goal of writing the draft and having the discussion was to get agreement on a sort of minimal set of administrative processes and conventions to have available for the community, so that foreign groups choose to use github. Then they could use these conventions. It's not a goal here today or nor was it a goal of the draft to decide like every single implementation detail of how to to carry out some of these things.

C

Nor, like how much of this to automate versus to have the Secretariat provide some support for there's a lot of really great work in the automation front. Already, Martin's, templates and rich is pretty much of scripts there as well. So we don't need to talk I. Think too much today about how to implement some of these things. Unless people really want to.

C

We don't have to decide those things today, but more I think some of the the conventions and process things, and then we can work with the tools, team and others later to get things actually implemented.

C

So there's roughly six of these that are outlined in the draft and I'll take through each of these. Today, creating an organization for a working group, creating a document, repo backing up an archiving migrating, an existing organization into an IETF style organization, handling personnel, changes in a working group and closing a working group.

C

So the first one is around creating a github organization for a working group and essentially what I'd like to do is kind of talk about what the features of how this is being proposed and then hear from people like. Do you think this is the convention that we should? We should go forward with, and a lot of this was inspired by what was already written in Martin's draft. It's just sort of picking a particular configuration, so the proposal here is that there would be one organization per working group.

C

The naming convention would be, as you see it, on the screen so get ready to bike shed the naming convention. The owners of the organization would be the Secretariat, the area, directors in the area and the. If you have an out-of-area ad, that responsible ad would also be one of the owners of the organization.

C

There would be a team of administrators for the organization that would include the working group chairs and the working group secretary. If there is one you have a question on this sorry.

D

This is a fairly ignorant is giving the slide.

C

So my understanding is that owners have the capability of adding other kinds of collaborators. People who know this better should get up, because I haven't managed a lot of these and but administrators don't have that privilege yeah. So.

D

Owners can add administrators. Is that that yes,.

E

Yeah, not in terms of this is not really all that important to this there's, not a lot of difference between the two of them. There's just a you know. We need to put them in some buckets pick. Some buckets I think that's. What Alissa has here was perfectly reasonable, so.

C

Just one thing to think about there and I think that might be reflected in something some of the later issues as well, and also why people kind of looked at this and said like who cares? Let's just do something I tried to think about this from the kind of longer-term management perspective. You have ad turnover. You have work.

C

My chair turnover like who's gonna, manage this through the full lifecycle of the working group, so that one just might be something to think about here is like which of these change more often, and where do you want stability and that's kind of why I thought the split made sense, I.

D

First thought that came on to me as a workgroup chair is my depending on my area director to actually do something you know: I can hook them know.

C

You're like fully empowered, but but you can't change yourself, maybe you can't change the people above you basically, which is the same as in the idea. So they can kick you out, but you cannot kick them out that matches to this arrangement. Yeah I.

F

Like all this, but Cullen Jennings, sorry a trivial NIT that we might consider somewhere down the road when I looked at thinking about how to automate a lot of this stuff, just creation of things it seemed and it might be much easier to actually just have all of the repos be have one organization for the ITF. Instead of an organization per working group, it might just eliminate a whole bunch of process. We have to do and result in it's the same in thing, which is anybody.

F

If it's no, my mantra is, it should be no more difficult to get a repo, that is to publish a draft. So if the draft name is draft jennings, I should be able to instantly get one. If the name is draft IETF you know TLS, then the TLS chair should be able to instantly approve that you know, and if it's draft IAB, then it would be. As you know, we know what the approval process is for all of those in a very trivial way would be no more or less complicated. That's a detail.

F

We could talk about either direction. I, don't think it changes. Much of this proposal one way or the other it's just like- maybe that would actually simplify some of this I.

G

Think we shouldn't in this IETF working group working more seriously, I mean III assume that the purpose this presentation was to give example, the kind of policies woman. Imagine having that we could then bike shed later on. Is that not.

C

I mean I would I would like to bike shed now I'm sort of like would love to come out of here.

B

And go: do it so.

C

There's things that people really care but like if you don't care about the details, that's a useful piece of information. But if there's details here that you do care about like let's, let's air them, because like walking out of this meeting, it would be nice to have sure.

G

A

Don't care but Colin's wrong about having.

G

C

H

G

H

You need to say, like can I just interject his jabber scribed Stan, York, John Clinton has reminded people to please say their names for the audio record later. Thank you.

G

Yeah because then, like every chair, is an admin of the entire, the entire thing. It's like it's the same kind of problem. We have a data tracker, we're like basically the ice controls are a screw up, so.

A

I'm gonna ask people to actually let our lists and get through the slides, because some of the site might be on the next slide. We have plenty.

I

On future, slides.

C

I

G

More point about this, which is that the that, if you have one Organization for working group, then you can also have the working group get out the I/o page that lists all the stuff for the working group, which is what everybody does thanks.

J

Bret Jordan I think that having a separate organization for working group does work. There is some administrative overhead that we would need to be. Mindful of so. There are best practices with large organizations that do use github, and there is a fence that people straddle some people say. Yes, you do one org and here's how you do that I mean this one. There is prior art, so who's not prior.

A

Aren't written down somewhere or even there's a good article. You can point to us. Yes,.

J

A

Can you send those to the mailing list because I haven't found those yes.

J

A

Bet that this has been done, yeah.

J

This is, this is well done and well documented, so my only concern is there's a little bit of a barrier to entry in using github and I. Think we need to be very cognizant. Of that. I mean working groups as they are now can sometimes be incredibly hostile and turn people off anyway, and if, if we get to I, wasn't gonna go there, I was.

I

There too, and I'm.

J

Yeah, it's a joke, but github is really awesome and great if you know how to use it, but the fact that there is not UI tools where I can you know, write stuff like in a Google Doc and have it automatically go into you know github is there is a barrier to entry and we need to be very careful that we don't cut people off so yeah.

C

And again, the idea: this is not to force it on anybody. It's just to like make this available for people who do want to use it, and we can. We can skip the conversation about big barrier to entry of the existing tool set for authoring and publishing.

K

Drafts, which is I.

J

Understand that and I as.

K

J

Coming in I, yes, it is, it is interesting, but we just need to be really careful that we don't turn people and if we go down this path and it's highly likely that it's going to be. You take ubiquitously adopted across the organization which could be really good, but we need to be really careful.

C

There's a few things like this that are ubiquitously adopted across the whole organization, for better or for worse, I, think yeah.

E

So mutton, Thomson I think I I agree with with that, good, to a certain extent, I think what what Cullen suggested here was was interesting, but if we look at the principles that we need to keep in this and how you might implement those principles, this is the conclusion that I got to there's that there's a certain value in having the degree of autonomy on the part of the working groups.

E

The working group chairs do need to be able to approve new repositories and manage users and assign people to two groups, and one of the things that gets kind of unwieldy in a larger organization, particularly with a large number of crafts and and a lot of things coming in and out is, is those things don't happen, and so realizing, of course, that it would be easier to do some of these things if everything was bundled together, what we probably need to do is concentrate more on making the the processes for doing these things.

E

A lot smoother about this I think that this is probably the balance that we're looking for right now.

L

Mark Nottingham, please please, please don't do it all in one organization.

L

That I think is is against the culture that we have here and that it like like Martin, was saying you know you don't have the autonomy for the working groups. It makes things a lot more difficult to fit what you're doing to an individual working group. Besides the whole github pages issue, which I think is an important one as well I- think that when people bring that up some or many of the concerns that they have in mind when they do that could be addressed with other tools.

L

So if we collect, if we collect better metadata in the data tracker to more intelligently link into github at the appropriate places, the w3c has a lot of practices around there, where they build whole tool chains around it, and you put a little file like a dot file in your rep out that contains a bunch of metadata. Then you scrape that and then you can build lots of interesting views.

C

L

The working group is doing based on that, so I'd encourage us to think in that way in a more kind of loosely connected way. Rather than saying everyone must be in this organization.

F

Clear-Eyed and fine with that being multiple orgs I, think the people who spoke to it or sort of reflected some lack of knowledge about github on that topic. Given how the actual github pages work attached to repos each working group would have its own repo, but, yes, you can.

F

You can also have one for a repo, so I think that the important thing to me is that it's automatable and it happens that I don't have to track down a chair to get my damn thing, approve that just is there and that's what we should govern this on. We both want this same outcome, which is it's really easy and low. Friction to this and working groups can do different things and can do whatever they want.

F

So I'm 100% on this I think it's it's personally I think it'd be easier, the other way, but either way work. That's fine! We're just just good I think the important thing is we're sort of agree on what we want, which is. It just happens instantly.

E

Someone tells I'm going to talk about something a little different now, so you've got a couple of points here on the data. Tracker, support and I think that this is about the right level. One of the things that I want to avoid doing is building a whole lot of spoke tooling. That says in data tracker. On top of this, that you have to go through that tooling and those processes in order to get any of the benefits that we that we're talking about.

E

One of the things that I like about the current arrangement that we have it is very much permissionless I can spin up a repo on my own under my own organisation and I, wish drafts and manage them there, and it doesn't require too much involvement here. Now, there's this and disadvantages to having a complete lack of support in doesn't rack up, but I think really.

E

What we want to do is keep that that that link is really loose and I liked the idea that Mark had which which was well well, once you have the linkage into the repo. Maybe the repo tells you about itself rather than building a whole lot of meta information in the data tracker and all this and some other.

M

E

Rather, look at that as a design philosophy that we have here, because one of the things that I've noticed is the dog tracker. Is this unwieldy thing? That's a little a pike in this. It's a bit difficult for people to contribute to that. Whereas if you put things on with their own control, then things just work nicely. Yeah.

C

I've been sort of thinking of it as like, because you already need to use the data tracker interface to instantiate things in the first place like when you're chartering, the working group right so like. Naturally, that would be a time where it would. It would be useful if you could have this automatically created at the chartering time, and you have to use the data tracker anyway, but otherwise like having things in coming from the repo makes a lot more sense. Yeah.

G

I guess I want to sort of slightly resist on this last bullet about orbit equation um on the big. There are basically two tasks or require administration right. One is creation, organizations at Woking do time or other on things.

G

In the second age creation of draft we posed for the for the individual graphs, I notice, you don't say like whether you're gonna have one draft repo, but if that is the right convention, I think we should so um um so I guess what I would say is like I know, people loved like prescribe these at ITF, but like the Secretariat order, arranged for what there's a button, you can press that causes or to be created, trough repos to be created, and if they were to do that by having data, her support them fantastic and it was to do it by having people do it by hand but accordions and script, and also fantastic.

G

um Like that's like a cost-benefit question that like we, do not need to get involved in as long as it appears to be the case automatic the road to be fast automatic. From your perspective,.

L

Okay, Marc Namie I'm, just one more thing in terms of the data tracker support to me, step zero, and all of this should be for data tracker and tools to make sure that wherever a working group is not using the other stack of you know, subversion and and the track issues list. They don't appear for that working group because it's very confusing for newcomers to come in and say: oh look, source, there's nothing there for five years or whatever.

L

If there are, if it working group, is using github, we should make sure that we don't have the other options visible. That's.

C

Interesting, thank you and thought of that before, okay, so yeah, we basically talked about the data tracker support items here, which maybe are a little bit debatable and then the last one here was a suggestion mark that is I, guess what probably was used in the w3c groups and other groups in the IETF to also potentially have notification weekly notifications to the working group Auto configured. So you get to see the list of issues and pull requests that have come in the last week, but.

M

The way this is sorry is Joel Halpern from Ericsson. The way that is phrased actually causes me concern and I, don't think you intend to, but the working the current IDF policy is that the place for discussing topics among the working group is the mailing list, and if it is not, there, I have a problem, because I am not in my normal workflow able to follow github stuff I. If for working groups, I care about I follow it a lot more than once a week. A weekly summary actually does not hit any useful point either.

M

There is nothing I need to know there, in which case I don't need to see it or there's. Something I need to know there, in which case I need to see it a lot sooner than once a week. So I can't build a model that fits ITF practice for discussion of issues and practicality.

M

C

I, thank you, I think. The the motivation here was really to just be like additional helpful information for groups that have adapted their models, such that they are having issue discussion on github and, as we know, there's like a variety of practices here and and well spelled out policies about when things come back to the mailing list and so on and so forth. I don't know where those well.

M

C

Out policy there are.

M

C

There they're in the github repos of a number of different working groups that are all using this method, so only.

M

Thing is spelled IETF policy. That's, but.

C

This Joel- this is the point of this- is not to harmonize any of those. Those are existing practices right. This is not about like forcing that model on anybody or telling people. This is how you do or do not have to do it, because there's like a really wide variety of how people are doing that right now, some Morgan groups are using github and they have no issue discussion there right. They just use it as like a place to stick a document before it goes into the ID repo.

C

So all I'm saying is like the this is just meant to be like additional helpful information for people not to dictate which one of those models that they use. Now you can argue with you. Can you can say that these working groups that have gone off and done this like this is inconsistent with what we're supposed to be doing in the IETF, but that's like a separate sort of policy discussion than this tooling thing, which is just meant to be a tool, even if that policy is consistent with IETF. Let's.

M

Assume it is for the moment for discussion. I can't figure out any context in which that weekly email to me would be helpful I just what other people can? Okay.

C

M

C

I go on vacation.

C

It is useful that would be helpful. Okay, yeah and this isn't even in the in the document cuz, it came in as a suggestion. Afterward you.

J

Used the V word I'm, not quite sure what that is. The vacation word I have no idea what that means.

J

Yeah, so I have a lot of experience in doing this with other organ. Very, very large entities that do this I'm willing to help and I think I, don't care so much about the digests and whether stuff is done on the email list or where it's done in issue trackers or whatever the thing is. We need to make sure that it's really easy and clear for people that are coming in, that don't understand the spaghetti mess of trying to figure out where things are done and how things are done.

J

I would be willing to share what I've done previously and I would be willing to help make sure things are crystal clear and easy for people to understand, so it I think we can do this it just once again it comes down to this usability side and we don't want to push people away because there's now an additional barrier to entry that they can't figure out so.

N

Excellent segue, because I'm coming into this and I was kind of a new news.

C

Reason Chris.

N

Lemons, a new person involved and the working group I was with uses github and also uses the mailing list, and they do so inconsistently and as a new person I just assume you know, there's a github repo I can open pull requests. I can file issues whatnot only to discover, after the fact that other people were thinking. Oh well, yeah he's not having any conversation on the list he's just ignoring us and of course that was not the intent.

N

There was a miscommunication about that, so whether you use the list or you use github or whatever that policy is if there was some easy way for a working group to spell out what expectations were for folks that come in I suspect that some sort of a two-way connection will be useful for some, but maybe not all groups, because in some cases it was just a lack of awareness. Well, I didn't see you open the PR. Okay, that's fine!

N

I've fitted a message to the mailing list that might have been useful, and so clarity is just is just key here. I, don't think you're gonna find a one-size-fits-all, but there is a is a huge population of folks that live and die by github and they love their github issues I'm one of them.

N

Please don't take them away. Okay,.

C

Yeah and I was Martin. Do you have you have a section of your talk today which is gonna focus on this or not? No. Okay, then we'll talk about it now so.

L

Marc Nottingham, um so in the HTTP working group and then later the quick working group excuse me: we spent a considerable amount of time figuring this out. If it's helpful, maybe if we have time live in the session, I can go through the current iteration of the HTTP working group, contributing document, because that lays out the terms of contribution and and answers a lot of these questions. It's been through a number of iterations, so hopefully that might help clarify or maybe make people even angrier, I, don't know which, but but regarding the mailing list issue.

L

I just want to point out that I've had very similar feedback from people on the other side who say they cannot engage in a mailing list. They don't have time to do it they're implementers and they find it much much more effective to engage in github so to agree. This is really a cultural issue and I. Don't think we can just say we have to do it on lists is that's excluding a lot of people.

L

We have to come to some happy medium, where everybody can participate in a reasonable way, but that might mean making some trade-offs well.

C

I mean I think that's true, except in within the bounds of what we have established, that we do in the IETF in terms of consensus and whatnot right, yeah, just one of the notes. So sometime when we were writing this draft I also took the examples of all of the contributing documents that I could tell that were sufficiently different from each other. There's like three or four of them and stuck them in the the main IETF repository. So we've.

L

Revised our since.

C

So, okay, okay yeah, but the idea was just to give people examples of different ways that it's being done right now. So so.

H

It's Danny work, I was instant, Here I am sitting over here to say my own, but then I will follow with the channeling of John Clinton. So my comment was to say I, think you're right to say there needs to be some kind of connection in some way and also I think there's a larger issue which Martin and I talked about it and he hit.

C

On briefly and.

H

His thing, too, that one of the challenges I think we need to figure out is how to help people find the conversations about some of these different topics when, because, historically, when it's all been mailing lists, you could just go to the mailing list. Archive and you'd find it. I was helping somebody who's chairing a group here, who's who was- or she was asked to help with reviewing a draft that was in another working group. That was using github, and she had been told that there was a conversation on this thing.

H

But it was an issue and then it was actually more was over in a pull request, and so I had to walk her through some of how that all worked and I've been looking at through her eyes. I realized how confusing it actually was to where some of the pieces were in that and so I do think we we need to figure out some guidance or something around that, so that we can retain that corporate memory, that organizational memory in terms of helping people be able to get back to that.

H

Even if it's in different places like that I don't have the magic wand to do that, I think it is an issue need to look at. If you make my hair a little whiter beard a little longer and pretend I'm John, he says with the understanding that I'm, an old fuddy-duddy who has never found w3, sees use of github an effective way to work and who has found effort in various IETF working groups even more difficult. My concern parallels Joel's and goes beyond it.

H

This is going to require very careful monitoring to be sure that it's supplements existing mechanisms, eg mailing lists and IDs. Rather than substituting for them. We, oh okay. Well, so now he's saying some of what I was saying. We also need to worry about two other issues, one maintaining the historical record and whether existing mechanisms for dealing with disruption on mailing lists are adequate or need additional tuning and two.

H

It is important to our process that someone be able to casually follow developments in a working group rather than actively and continually participate in a discussion and github can make that very difficult unless great care is used. Thanks.

C

There is a later slide on backup and archival. So talk about the history stuff, Harilal.

O

Lustrum relaying some experience, the WTC working group that cost they lost the tool on the last line to be created with mine, so I suppose I shouldn't be accusing drove all over sterling lack of imagination, but they we have actually found it quite useful.

O

We tried a few combinations and some of them definitely don't work at the moment. We're running with a combination of notifying of new issues of the father on the list, which is the one being an old Farrah, daddy, I personally use to figure out that I have to go, look at issues and the weekly the reg digest. That tells you. Oh someone has updated an issue and I didn't see it. Oh I have to go look at that.

O

It's actually important that those messages, automatic messages to the list contain links so but I wouldn't say it works well, but it seems to be working for us having a crowd of people, some of which wonder what amazing is this and some of obvious who wonder what github is so yeah? It kind of works. We get things done and weekly activity. Digests is one of the components that I wouldn't say it's critical to make it work, but makes it flow. Thanks.

P

Everything just one comment and out of this slide as the OT coop share I would be more than happy to use the tool like youdescribe. As a 9tf author of to ipv6, only draft I will be ashamed to push my draft on an ipv4 only system, though thank you, I'm glad, I'm glad you came to the mic.

C

P

We push a draft there. Will you have something like a javis job, checking with XML to ever see the syntax or XML? This is part of the tolling already yeah yeah.

Q

Yeah yeah Martin stuff, Scott, continuous, integrate sorry rich Saul's, Martin's stuff's got continuous integration, build so they'd. Actually, by the time you post it to the data tracker you're guaranteed to pass no ID nips, and all of that um point I want to make is I. Think it's not that this is better or worse, but it's different and as we're talking about you know, IETF e-participation dropping right we're below a thousand this time around and you look at the potential people on you know the github population. We really need to make it.

Q

We really should be making an outreach and getting people that have never come before and they can scroll through all of his item. These guys are defining HTTP I care about that. So don't be scared. I.

G

Sure this is a bullet point. That's important that got missed, which is quick to automatic setup of the CI jobs. That's actually probably the most unpleasant part of the entire operation, so yeah, that's actually like, because you need to like set up like someone theses at this up and circle or Travis or whatever, and your dummy accounts like a beep in yeah. So on having like secretary him, that is actually probably the most painful part.

C

Yeah this, it is here on the on the repo slide, so so for document repositories. There's lots of different kinds of situations. One might find oneself in wanting to migrate an existing repo wanting to have a repo with multiple documents, again thinking about like minimal requirements. The proposal in the draft here was the the part that we would kind of support and automate would be the creation of a document repository for a single document, that's kind of the boundary of these case. So you know, any administrator of the org could request this creation.

C

The collaborator, the collaborators would be the document authors, the name would be the draft name and then it would be automatically configured with. You know skeleton draft file, all the boilerplate documents that you would need. We could default talk about what what goes in that contributing file. You know some sort of boilerplate one and CI support.

R

John the next I feel like it would also be useful if the same tooling could be used to create an individual submission in your own organization, which could then be forked into the working group when, if it becomes accepted as a working group document, so that you know you can keep the pre acceptance history and all that. How easy are these? Is this tooling to point it? Something that isn't an IETF I.

C

Mean the tooling is the same right like this is effectively what.

R

Including all the stuff about automating, the seenu's integration, that's.

C

All that that's the part, that's already done. The part that isn't done is like is basically the naming conventions and deciding like who who's responsible. For this thing, yeah.

E

So there's obviously things we can. We can do to improve that process, but but ultimately, I hope that the process for making an individual draft or making working group drafted functionally identical and the process from transitioning from one of the other is relatively straightforward up on instructions. So I had to do that. You just have to go into github and tell it that you give permission to move it somewhere and it just goes so. I don't think that's particularly challenging either.

F

So there's two things: we're talking about: github Collin Jennings. Again there is the the draft document, of course, which is easy everything we just said, but it turns out the part. That's far more sticky and harder to deal with is all of the issues and the PRS and comments, and all of that stuff, which you don't want to lose that history, as you move from one to the other and I think that that's again was one of the things that drove my previous comments. Is you know?

F

How do we set this up so that the individual repos? You know that that all just happens and comes across I think it's critical that we don't lose that, however, we do it and everyone says it works. Just fine. Everyone has a view of how this will work as long as we did it exactly the way they were thinking, it would work just fine, but there's about five different views of what would work. Just fine.

G

You just read: Morton's.

F

Tooling, it makes it very.

A

G

A

You we, you know, we've got just a few more men. We hold this until the open mic line at the end, also because.

C

We weren't actually been suggesting the migration a bit, so that would be. That would be I mean it might be very simple to do, but I wouldn't.

G

Consider that to be in the minimum sure: well, actually it's just it might be easier simply to have, um just as we allow anybody to make an ID to allow anybody request the secretary. It makes it a repo for their individual ID and then everything be very straight forward and we wanted.

C

G

C

So maybe this will be the last one that we do. The others are not a big deal so, but I know that yeah.

H

I'm sorry, Dan you're. Could you go back to that one? No sir I guess my maybe I too need that how easy it is because I create my drafts in my own individual repos, and then, if one is to become adopted as a working group that repo needs to move into in this environment or it would be a new repo created in the working group organization. So then, how does my content you from one place to the other Martin showing me his is okay. Look at that adopting that transfer the repository there.

H

We go okay as long and that this I think points to another point: I think as I look through Martin's materials.

H

We do need kind of clear, concise guidelines for new users to github or new authors about the way some of this works, because it's not entirely clear for people getting started in it. Yep.

C

Definitely more on this. You.

E

Can go back to vacuum? Backups, okay, so I have something here. It's terrible due to various constraints. If we have fewer of those constraints than this repeat, would be better I also elaborate.

I

So sorry, what currently the.

E

Process that I currently have for doing this is that every time you make a commit to the repo, it runs the CI job and as part of.

B

Running that CI job.

E

It determines whether or not it's been then enough times elapsed since the last time it backed up and will make it back up. Unfortunately, though, it collects too much information. That's not really all that useful. It's in a format, that's not particularly ideal, but it is still all there and I do have at all to render the issues that that we're opening, you can query, do a bunch of other things, all of which you can do offline if you have a copy of the repo.

E

So there's some advantages to this tooling, but it's also acknowledge not exactly perfect. You.

B

Don't get the full discussion.

E

History, because crawling through all of that would take too much time but- and it was it's also already quite big- for Quake, for instance, but it's it's all there so having.

B

An having a workflow, that's similar to.

E

That would be would be kind of ideal, but there's there's a few things we could do to improve it. Okay,.

D

Good, actually I've got a an agenda bash, so I think I'm gonna. Let you finish your presentation.

A

C

Yeah so I think I mean maybe Paul if you want to speak to this, but when we sort of throw some things into this draft as potential suggestions with not a lot to back them up. So I think this is definitely an area that we need to address. If we're gonna go out and say here's a full set for people to use- and this was just our initial thinking on that so actually Paul's initial thinking, cuz I had no idea.

C

So how are we? How are we doing?

C

The last three are again, these more sort of long-term like if, if we have an existing organization or an existing working group, that wants to like have its privileges and name adopted into this convention? That might be a good thing to do.

C

When there's personnel changes in a working group, it would be nice if those were automatically reflected in the relevant organizations or they actually need to be right, like we don't want to maintain people with privileges over things that they're not supposed to have anymore. So we need to mirror the organization that we have in the ITF in the in the github organization and then same thing for closing right. We don't.

C

We want to have some wrap up process, which is you know, consistent over time, so that we don't have repos sitting out there that appear to still be open. When we've closed the working groups.

A

Okay, so those last slide.

L

Would you archive the repos, yes.

A

So github has the ability to.

L

Explicitly archive not.

A

Necessarily, well, you wouldn't make sure they.

L

Were our I would I'm.

A

Sorry I don't mean.

L

The sense of saving a copy I mean the sense of there's a processing github where you press a button and it doesn't take any more input. Yes,.

A

That's a thought: please bring that to the list. Yeah.

L

That state is explicit: you can see it as a user yeah good idea, sure.

A

If you want to agenda bash yeah.

D

So I I am so in my working group there's some folks who are using a private github repo to work on a couple of working group documents. I mean kind of stalling, doing anything with it until this makes progress and so in the meantime, I've been kind of watching it a little bit but I'm I made a novice, github user so but I'm I'm sensitive to the comment.

D

I think that that Joel and and and John raised, which is the notion of being allowing people to with who are deep in the development of a document, try to understand what the issues that are being discussed, so they can figure out whether they have any concerns or not.

D

You know it's it's one of the big values of what happens in the IETF is the cross-disciplinary contributions, and so we want people to be able to see that, and so I've heard some mention that there are tools and people have ways of doing with it, but I and I glanced at Martin slides to see if it was already on the agenda and it doesn't look like he addresses it specifically.

D

But Brett said that he had some examples that and I think that that's actually to me, that's a really important part of the story that I haven't really heard a satisfactory answer, and so, if somebody has stuff that works, you know to address that specific point. I'd really like to see, like maybe a short demo here, because otherwise I'm going to walk out of this still uncertain whether it's a good idea for my working group, so.

A

If we have time on that, you.

C

D

A

Can come up and plug in that would be great and.

C

There's a recording of Martin previously demoing it writing from the.

E

Last session I got the working various lunch in it. I went through a bunch of more detail, yeah.

D

E

Think there's more to be done. Lee yep.

C

E

Probably shared with everyone.

A

Well, I'm, sorry and I'm trying to get this. This slide didn't actually update in the slides that are in the set. I actually have the URL for the mailing list. Getting this going on the mailing list, we obviously have been hearing a lot right now, getting those things going on the mailing list ASAP, since we now have a large new group, you know, let's list of things I think would be really good, so I.

G

Think one of the things that we need to make sure we don't get about is. It is true that it can be very hard to follow, discuss, find github. It's also drinking all right, we're here to follow discretion on the mailing list. The I think it's important to confused, not to confuse about the fact that part of the palm is just volume and that github has caused like an enormous source of participation and a small participation on on individual things.

G

Like you know, here are three long changes and that causes a lot more like a lot more traffic and a lot more on, you know stuff going on, then your ordinary mail on this traffic would be like ordinarily, like I would make you know hundreds of changes as an editor and then just lay in.

C

G

Opposed to you can track every single, every single, comma, Chama change, I make and so like. On the one hand, this comes with a you, get like a normal, see, more transparency and normally more like engagement from people outside the ITF. Now the consequence is enormous, want to traffic at the hall of no arrests or on get up in notifications, so it's important might not like to get to like not they get to when they asked on the two links. What we're probably seeing is just like a change in like engagement level.

C

So I think so. Thank you. This has been really helpful. I think Paul and I will sort of take all of this feedback. Back, probably revise the draft and I mean. It also seemed to me that moving forward on some of the tooling things, people were kind of ready to do that at the same time as we try to develop some guidance for newcomers, so I think that's the plan coming out of this yeah.

A

Trying to right click and this isn't a Macintosh. So therefore everything is wrong to Sanders.

S

A

S

A

Works, that's like yeah I would have thought of that. Ok. So let's get your document up, though.

T

A

There's a pink axe: oh.

U

E

Also, a clicker.

A

Here I have a clicker thank.

E

You all right so I have a few requests.

V

E

Just wrecked it.

A

E

A

E

A

It says never full screen hit that button. I did since I when he.

E

Hit it again, it yeah that's.

A

Right so I thought it would be fuller, moving.

E

On the the idea here is I mean Alissa's thing is obviously here to just make the current practices that we have easier and fix the things that irritate us make all those processes that take a long time and complicate in an error-prone that much more streamlined.

E

I'm, also wondering whether or not this and guidance that we can give to those people taking those practices so that we knew people can take it into their working groups without having to relearn all of the things that we've learned over time. I think there's some good examples of working groups that have been quite successful at this and then the last one is we're not going to force anyone to do any thing.

E

I think that's where we got to in the discussion on the online, how we structure organizations and how we manage them, and it's probably worth worth highlighting the fact that if you're working group is perfectly comfortable with the way they're working right now, nothing needs to change. But we can.

E

We can probably help people out a little bit without making things worse. So we talked about this one here. I think this is exactly the stuff that we talked about. I do have that point that Erin pointed to here as the first one. It can be a little daunting. Getting this thing understood and getting the process going, but ultimately, I think what Alyssa's that suggested here was was really important, though there may be a variation in ways that people work.

E

It would be really useful to have a particular mode that we think is sort of the best one for whatever it's worth and pick that one and double download and provide a lot of support for people who want to follow that path, which means that people who participate in multiple working groups then are more likely to get a consistent experience in those working groups and will have a larger community of people who can provide advice on what to do in certain circumstances, because there's there's much more uniform experience across those I.

E

Look at that. The draft suggests a number of things: how many organizations one per working group, who owns them again same recommendations?

E

How do you maintain this so I thought that I had when writing this up? Was that the set of owners on a working group and the linkage between those sorts of things could be checked automatically? So if we have the the metadata in in data tracker and and some other things around, we can we can go hey this. This particular repository is owned by this particular working group and it has the following set of owners and admins and and editors and authors.

E

It was double check across the infant between the information there's in data tracker and the information that we see in github and make sure that that's right on an ongoing basis. So that's another idea that perhaps we could we could automate and so that someone would get notified when things get a little bit askew. So if there's a change in area directors, we would have a nice nice list of emails in our inbox that we can look at and say yes.

E

Well now now we have the following actions to do and the final question which I didn't have enough space on the line to put a suggestion. Not for but I think I've got an announcer from discussions here is it it would be really kinda nice to have that Secretariat have access to the organization's for the purposes of doing things like make a suggestion of being able to create in your repo under the org.

E

Things like that, obviously, would have to set some parameters around that, but that would be that being where I've been thinking on that one.

E

So it would be really nice if we can have a set of boilerplate policies or chairs to pick up now. Ideally, there's sort of only one of them, but it's quite clear that there's a number of different work modes that people have adopted, but particularly divided between whether you have substantive discussion on github or whether you just use it as a repository firm for drafts and state, or whether you have the formal issue, discussion in github and whatnot and having those policies available.

E

So the chair can just pick it up off the shelf and use one of those would be nice. Ideally, it's one I suspect that we're going to end up with with something like two or three to come out of this and that's yeah. That covers things like how how contributions are made to the group and where do we resolve issues and we've had a lot of discussion about how the substantive issues resolved and how who is responsible for managing that process.

E

The current HTTP process and quicker is very similar is then that we will open an issue to track and github you'd attract something we will follow that through and have a discussion on that issue on github, and we will have the editors closed at issue when they believe it resolved now. That doesn't necessarily mean that there is consensus on that.

E

The editors make their own assessment at that point, but as as a policy, we've found that having the editors of a particular draft responsible for managing everything that happens in that repository has been the best way to to move forward. There's a bit of discussion in the draft I think that's on that as well. I do actually.

B

Have a zero one.

E

This is the funniest thing: I've had a draft that I haven't revised for a year and I'm still talking about it.

E

Labelling is has turned out to be rather important in her work and having a set of policies around. That I think would be good, I think rich proposed in the setup tool that that we sort of set up that the labels automatically having consistent labeling conventions would be would be interesting.

E

There's some discussion to have there around different conventions, perhaps for repose that have multiple drafts in them, as opposed to repos that have single draft in them, because because this is a an interesting question about how you manage triage of new issues, but that's that's a discussion that we should have then dan you're. So, oh, when you see labels who talk about it for the issues yeah, so we manage. We manage a large number of issues in quick and we're almost up to 2,000 of them.

E

Now and, and we've heavily relied on labels to make sure that we can. We can do that effectively and I.

E

Wonder whether or not there is a recommendation we can make for your working groups, who haven't got the experience to make their own minds up about what the right policy is for then about whether we we pick a particular path and bless them as well. When you'd said earlier, possibly a couple of policies right.

B

But we might still pick one.

E

Of those and say this is the one we would prefer you maybe.

A

E

I can completely.

A

See a to policies of lightweight and heavy weight, whereas movie night wait right then HTTP this would certainly fall under heavy weight and I can certainly see a lightweight one. That, for example, didn't use labels right.

C

A

The word and whoops I'm in use labels and they're, okay and I, totally understand how you would die without right.

E

And so a lot of my personal drafts I use labels on them. Eight, that's right! For the same reasons: yeah.

J

Yeah so I would follow along with that is you know, having maybe a heavy weight or a symbolized version would be really ideal.

J

You know when it's great when you have conformity with labels, because then people coming in understand what is going on and what do they mean when everybody has their own little pet peeve of what they want to do and what they don't want to do, what color schemes or whatever it's just madness, and you can look at this in a large vendor that produces you, know, lots and lots of products.

J

You have different repos and when they're all set up individually as a product manager, it is a nightmare so but I think we have to realize that there's going to be some working groups that are going to be very simplistic and then there's going to be some that are like quick and I think you know this two to three, as you say, I think would be ideal and realizing like the label structure. We should follow that same view right. You know.

J

If you're not gonna use labels great, you don't have to use it, but we're gonna set up the bare minimum that you need to have, and maybe there's five, maybe there's seven, what some number and then, if you're quick, you know or something like quick you're gonna. Have you.

C

J

Or 20 or whatever they are, but we should define those so that there's constancy and you know, ease for people that are coming in and then and that's my soapbox is people coming in. You need to be able to understand what the default foam we're doing.

E

Yeah and and so I think there were recommendations about having a consistent set of labels even to the point of saying that they're the same color, it's it's, it's weird that we start talking about these sorts of things, but that's that's where we've ended up. It's been really useful. Having.

A

Right exactly yeah.

Q

um Yeah I just copied what mark he goes along from working group to working group and replicates the structure so I just script to fight it um don't get caught up on the labels. It's really trivial to make a label to delete a label. It's just a category for an issue you can edit the colors. You can easily migrate all of what used to be called show stopper to resolve really trivially. So just don't worry about it.

E

Yeah, there are good tools for that, so mark.

L

Nottingham I'd, second, that we have evolved or approach the labels almost constantly very incrementally, but you know there's some practices that go back to the very beginning, like each draft gets label and it's yellow and that it's just a nice visual clue and yes, we're talking about color, but we've refined it over time. I think that's appropriate. We're still learning I haven't heard anyone saying: oh, the label system is confusing. I have heard a lot of people say. Thank you. That's helpful.

L

Just a pointed data of the h-2b core documents have seven labels of the HTP extensions, which is probably our most complex record, because it's a multi document, rep Oh has 27 labels and most of those are just identifying different documents and the quick base drafts has eighteen labels, of which one is unicorns. Exclamation point exclamation point off line. We should talk Martin, my.

A

Editor about the number of exclamation points or penis: it's it's a nice pink, color yeah!

A

E

That sort of comes to the next point, I think one of the things we've learned is that it's it's kind of important to to use the mailing list to confirm consensus in one of the things that we found was that, though, github attracts a lot of participation from it from a certain set of people. It doesn't capture the full breadth of working group participation and so having having that confirmed on the mostess is hugely valuable, particularly when you don't go there all the time.

E

So, if you find that there's a lot of there's a lot of high velocity discussion on the issue tracker, the email stand out a lot more and they get the attention they deserve, which I think has been really valuable in the discussions, particularly in quick when we're we've had sort of the really complex and meaty discussions on the mailing list, and that's that's given us that the time and space that we have for doing that without really slowing down all of the high velocity work on.

E

You know whether whether commas are and all those sorts of other things on the issue tracker, which I thought was really good. We.

B

E

The bigger issues to the mailing list, even even though they may have been completely resolved, if we think it's important, will will surface out on the mailing list and and there's some advice, I think in the draft that talks about this one I talked briefly before about giving the editors control over the issues and one of the things we found was that close it having the editors, close things and being able to do that was was kind of critical to all of these things.

E

Otherwise, you went up in these weird states where you have to use labels to indicate things and all the sort of things that the editors believer resolved still get in the way and it becomes really unwieldy. We do have in the HTTP repos a label that we use for particularly contentious issues. That says this one has working group consensus and they and the editors are told not to use that label, because that's something that the chairs will process this.

B

Is all part of the policy.

E

That we would want to build up in in these things. One of the things that we found is that it's very very difficult to follow the discussion if it happens on poor requests, and so we would advise people against doing that. One of the things that you find is that someone will make a comment on a change on a particular line.

E

The discussion will spool off from that particular point and then the PR will be changed and that disappears because it's attached to a line, that's no longer being shown in that in the diff and it gets really confusing, and so we've tried to steer people away from call requests as a as a venue for discussion. There's just little lessons that you pick up over time. That I think we should probably write down at some point right.

J

Yeah and I was gonna, bring up on the pull request to that's. That is an issue that I've seen over the years and then also bringing stuff back to the mailing list. I think it's really important for editors, authors or chair to summarize key things that are going on so for organizations, whether you're in this one or you're in other organizations, and you use github or use slack. You know.

J

Sometimes you get to a point where you have two hundred thousand messages that have gone back and forth, and people cannot keep up and it's a few key people that are bickering back and forth over some semantics or normative prose, and once that has kind of gelled. Amongst that group, it is imperative that the chairs or the editors authors, bring that back to the list and do a summarization. This was what was debated. These were the people that were involved.

J

It's important that you call out who was involved so that people understand like what was the scope of it, because if it's three people saying that oh this is, you know we have consensus now, because three people agreed it's not consensus and when you bring it back to the list, then people that are just paying attention list can understand. They can have an informed decision. They can know what it is they're supposed to be thinking about and talking about, but it does put an onus for myself. You know as a chairman in other groups.

J

It requires a lot more work, and so we need to understand that chairs are going to be responsible for doing this and it's part of the job so.

E

I found that to that point, if the chairs have to do that job, your editors are failing it at some level. So one of the things we found- that's worked really well, particularly in HTTP and quic, is that editors take responsibility for doing this themselves, or proponents of issues or what-have-you will will actually come to them. Do this carry work themselves?

E

Obviously, if they can't do things like summarize consensus or anything like that, but they can make sure that those important things come across to the working group and that takes some of the load off the chairs. Of course the chairs are watching, and if someone missteps, then that the opportunity to correct that, but right.

J

But we also have to be careful that there is an inherent conflict of interest. We knew trying to summarize a discussion and you're one of that proponents of said view having an outside person or a party, a chair which a chair should always be outside of the debate so that they can be unbiased and they should be able to come back and say this was the issue.

J

This is our perceived consensus on slack github, whatever you're using and here's kind of where things are at so that we can make sure that everybody has an informed decision-making capability so yep it.

E

Just has to happen, in my view, it just has to happen somehow been.

V

Connect with respect to the discussion on pull requests topic in unenlightened groups using github I've, always found myself when I'm looking at a pull request, trying to figure out what happened here. I just go through and click on, your show, outdated comments for every single entry, yep and then I go through and read. What's going on.

E

Yes, you can do that. It's a little difficult, there's, also the ability to take one of the comments and turn it into an issue. There's a there's a little menu there and I encourage people to do that too, because it means that it surfaces. Those really important points.

L

Mark Nottingham yeah: absolutely we just no discussion on pour requests. It's you have to really ride that hard center.

A

Over where you prevent.

L

A

Couldn't find what I.

L

Was hoping you would say? Yes, so it's a cultural thing. We had a problem with it earlier and quick, and we just had you know the chairs. Then the editors just made it a habit there. We time you saw it smoosh it go, do an issue yeah and and and or take it to the list.

E

You have to be able to comment on the pull request because it I want the coma here rather than there, and we can have a discussion about what that what that means. But when, as soon as it becomes substantive, then you really have to recognize that point and yeah yeah. So.

L

In terms of the previous discussion about reporting back to the group and keeping people aware of the changes and and summarizing consensus, that is something that we've struggled with the various degrees I. You know on the HP core draft, the the guys are really good about porting changes in the document themselves. We used to have a habit of summarizing the changes to the list.

L

Every time we were at least a draft personally I would love it if we had tooling that could take the get commit history and the tags and automatically generate that chunk of text that we can stick into the draft and some of mailing lists with the appropriate links, the diffs and the issues and everything, and it just works I'm almost there, because when we were doing Age, 2 I was doing all that manually for every draft as the chair- and it was a freaking nightmare, tooling, would be great there. So.

E

My offline backup, if you are from the dev, the developer tools, console.

L

Visib isn't.

E

Like one instruction you can do and it outputs a change, look I I.

L

Want to get it so I can just either have it paste it into the draft, or you know down at the bottom of the changes.

E

Look I get that or I.

L

Can paste it yeah, but but in terms of consensus, I guess: we've had this interesting transformation where, when we first started doing this, we used the github issues list to record consensus. So we had a has consensus flag and we had a you know, and we did. The consensus calls around the issues and- and that is it's a lot of process around it and I I think we came to a point where we weren't convinced that it was actually helping in terms of consensus. So we've come up.

L

We've we've migrated to a much more dynamic, I guess model where the only place we're using that has consensus flag is when we have a truly consent, contentious issue and we have an explicit consensus call in a list. We want to remind ourselves that we did that, but it's not for every single issue. Our attitude is- and this is in the current contributing document for HTTP. Our attitude is that the final judgment of consensus is in working group.

L

Last call an IETF last call and everything before that is moving towards that, and if we can have checkpoints along the way where we can confirm that we're in the right direction, that's great, but it's not like well issue number 453 has consensus and we can't reopen that for every single issue. I don't want people to think this is something we really try and make explicit in our contributing document is: is that the issues list is not the reflection of consensus? It's a reflection of how we are managing the discussion to get to consensus.

E

And so one of the things that we've been very clear about in in this policy is, if you think you have new information and the issue is closed-open it and we're very open to that sort of thing. Just because we only have 20.

U

Minutes left for the working group- oh I,.

A

L

None Gordon group forming buff one other important lesson which is known here is: is that using the github pages is a great way, especially for folks who aren't that conversin github to give people a set of links and a set of entry points into the work. So they understand how to navigate it, and we've done that in HTTP and quick and the feedback we've had is good on that.

H

So mark just led to it's dan york so mark you just actually led me to another point I was gonna mention, but first martin. I think your point.

C

H

In the poll worker in the PRS to be able to change the comments in the issues, that's the definitely kind of thing we've got to capture and help to less less github savvy people to be able to work with. In that regard, I think mark to your point and martin, you mentioned us in your draft the that about creating a going down and a little bit more granular here into the individual drafts and creating a text version people can can be able to look at in that way.

H

I think that is something that that does need people to be aware of, or to understand I mean when I do my repos I, just I save a version of a text copy directly in there I.

C

Do it because I it's.

H

Been the way that I found the my own individual ones that I let people to be able to go see it, so they can if they want to review the draft thing and there the text version without having to go and take the XML version and go and generate their own type of thing. It's.

E

Like take a look at the quick repo that we use, github pages is automatically generated nice HTML, it's much better. So.

H

So I guess I would say again. This is where we need to get guidance for authors of her new authors, especially about how to do this kind of thing, because I'll be the honest and say I, don't know how to do that. So you know I need somebody that I mean I'm, sure I'll, look at your things and be able to figure it out, but we do need to be able to provide people with that kind of thing. Now.

H

John and Clinton must know when I'm about walk up here and say something because then he throws something in here at that moment, so pretend I'm John again think about that quote: bickering back and forth, unquote and trivial editorial changes of the variety for which we historically encourage private notes to the editors. Not working group lists discussions in the context of what it does to the volume and signal noise ratio of any automatic backup and archiving system. I.

A

E

A

Gonna move but they're tagged editorial, alright, so.

E

A

Really are yeah.

E

A

Else have we got ultimately.

E

We want to make make sure that's easier to do the things that we're doing here, one of the one of the key complaints that I've heard is that people see a draft published and they want to be able to contribute, and they don't know how we need to pave that path.

E

We don't want to put policies around people contributing we. We just want to let people open issues and pull requests and what-have-you and simply be prepared to deal with the consequences of that and yes, that sometimes means it's a little bit more noise and we automate the processes where we validate changes.

E

I think the CIA setup that we have has been really valuable and then maybe some people aren't happy with the level of sort of inequity in us that is being involved there, but I mean you'll get over it eventually, I think we've already got through most of these ones. I'm gonna do this last one as soon as the data tracker actually has the ability to do that, and that will happen automatically for the folks using the tools that I have I.

E

Already have tools to make it possible to snapshot the work and uploaded a data tracker as an internet draft with a number on it, not familiar with how that works. You tagged the repo.

V

E

Tag and it just happens, you get an email and you have to confirm that it's part of the authentication we have and maintaining the readable copies, as we pointed out, is, is crucial for people who are contributing I, don't think anyone who contributes too quick on an ongoing basis looks at the internet drafts that are in on the data tracker. There look at the editors copy, because it's that much more accessible all right now, because we weren't having a working group forming baths.

E

Here's my idea right a working group to work on these policies and develop a list of requirements for what it would take to implement those policies and make the stream load most policies and I think that'll. Listen might have said exactly the opposite, so be interesting to have this discussion and she's the ad she.

E

She has an opinion too and I respect that opinion.

A

E

So I don't expect this would be particularly complex, but I'm suggesting that perhaps after this session we we're not going on a charter and try to work out one salutely. What the work would it would look like, but I think there's that there is some work to do here around these policies and sort of normalizing them. Just a little bit. I spoke with I think now reached the point where we've got sufficient experience with.

E

What's going on that, we can at least take the first cut of this and roll it out a bit more wide, widely and and keep people and officially blessed work practice and double down on the tools to support that work. Practice right. Disarmed.

U

Fred Baker I was part of the tooling, for that would we then be setting up a I ate a free party and I eat yep service? There is a no idea of organisation already, but if the the.

E

U

Here is to computer running, something like it. I'm.

A

Afraid you're asking.

U

A

We be asking a.

U

Mouse or whoever to set up a computer so.

A

U

A

Has not been at all I.

U

A

We're not going to fix the ipv6.

U

Problem Oh terrible yeah.

E

I think that's an antique golf yeah.

Q

Just to Claire, while you can actually run on Prem github, you can run on Prem gitlab right, but you can only do the hosted.

E

Servers for github, so the value of github, to my mind, is primarily in the community of people that are participating there already. If we, if we were to set up our own, we would lose all of that.

C

Alyssa Alyssa Cooper so just to clarify you're, proposing a working group, because the thing that you feel like needs, some sort of consensus is which set of policies are going.

A

To be recommended.

C

A

I think working group also might be useful, so we could have an interim I. Don't think you can have an interim for a boss if.

C

There has been an interim boss before didn't you. Do it into her mouth.

R

A

Out of time, I think an interim would of showing tools and such like that would be useful and such like that I don't want to have to set up a working group just to have an interim but ya, know I.

C

Mean we can have a conference I guarantee.

I

C

Don't need a working group for that I. Don't know. I just I feel like the the feedback on the list when we proposed the boss was sort of like. Why do you even need a buff like just go?

C

Do the stuff- and you know, spending of a warden group can be done with minimal overhead, but it's still some overhead, so I would I would like to hear from other people if they think it's it's needed or you know, go write a charter and put it on the list and, let's see, but coming into this I sort of thought, people thought. Even that was overkill. We could just kind of keep talking about it and then go do stuff.

C

E

Was just a half-baked idea when I was you know out of my skull sick? So if, if this doesn't work, then this doesn't work I do think that we need to need to do these things. However. However, that happens but and I think I need you have consensus right, and so that's why I sort of sitting sort of gravitated more towards the the working group side of things they're supposed to be cheap. If, then, if they're not, then maybe we've done something wrong. Yeah.

G

I mean that matches my view. I mean we. We need to do some work and we need to like publish the documents and talk consensus on it, and we have some built-in mechanism that so he might as well like use the McClung key though they are.

G

Studies and stuff, so maybe a study we get him yeah.

E

We'll call it a study girth, so um you you will note that I've not proposed anything here related to the draft that I am talking about which is well inspired. Well, I didn't talk about that draft when I talked last time, either yeah, but still Adam.

F

Roche, if we're developing a to-do list, I want to point out that I heard in this room and I think I heard last time. Also a desire for like better training on github in general and the tools you built around it so I might encourage you to consider doing an edge you session for working group chairs on a maybe periodic basis. If you up for it that walks people through exactly it's like this is how you would get the tools.

F

Here's how you create the repo and I'm gonna, walk through creating a sample document and show you which buddies.

A

Depressed me, I actually did that like two or three years ago, and the mic line was similar to this one, which is every slide, had 12 people. So that sounds.

C

Like people were thirsting for knowledge, that.

A

Sounds extremely is it was. It was as active with working group chairs as it would be with you know the edgy for beginners when.

E

A

E

Lost mating was, was pretty well attended and had a great discussion as well right, I'm, making more from a training perspective. These have been exploratory right. Yes,.

E

This can be our mock. I'm gonna go sit down all.

B

Right leave this.

C

Here, though, unless.

E

Portman and.

B

I'm, the first in line for open mic live. He was also in it. Has anybody thought to ask the tool team what they think of this.

A

Or anybody ELISA.

C

Cooper, yes, in fact, the tools team, oh the tools, team, who's coming to the microphone right now, so maybe I'll just I can just let him answer but yeah. We we talked to Robert about everything in our draft at least.

C

A

I, just I just hit the button for Robert, so Robert yeah, so you know we're paying attention. Okay,.

A

Thank you for paying attention so.

W

Henrik lived Corbett's, so it's good that Robert. What was aware of this I wasn't. So there is maybe a bit of lack of lies in here anyway.

J

Bret Jordan I would support if we want to go down the workgroup path. I think that's fine, I, think it deliverable coming out of this. In addition to the policies, is some really crisp clear documentation for how newcomers you know come up to speed on this? Yes, there's gonna be bike shedding and people are gonna have little little. You know pet peeves with whatever, but we need something, that's crisp and clean and easy to use. Otherwise, it's just gonna be a nightmare.

H

Daniel +12 that but also I, think there's some other pieces. Martin you've got down before, as I said, but Nelson I think there's some things. We need to think through tuned for the individual authors. In terms of you know, just what practices do we want to encourage around tagging? You know it of the repo and in pieces like that, and you know naming of files.

H

You know just some of the ways that there's I think guidance that we can offer to people when they're, starting out and I think also I'm says that I've been trying to help people get started, writing drafts and get started with with working with some of this and I think we need to make sure that the tools that we offer you know that they are also accessible to people who are less savvy in some of just the usage of github in pieces, like that and I.

H

Think one of the other parts we have to look at too is how do we give people the ability to go and and do some of the things they're used to doing like in data tracker pieces around, for instance, of different files that are in Innes in a different versions of things again,.

C

H

Brett's point some of that is education and development of the right tools and pieces like that.

L

Mark Natyam uh to the education question, yeah I think in Martin's tools are amazing in their capability into one place where I think they fall down is in documentation, and we've talked about this before I'm willing to help out to improve that and hopefully reduce those queues, yeah yeah. So let's, let's actually put some work into that I. Don't think we can ask Martin to do much more because he's done so much there already. So.

A

I would ask you, since you are a working group, chair of a group that has actively been using them, and you don't have that many authors active right now in your working group, is to ask the working group to help on that, because these are people who are experienced with them who know them, and some of them might remember how it's sucked to start using them until they got to know it. So you know you you it's sort of like when when we say hey is there?

A

Is there a professor on who has some grad students who can work on this? I would say, are you a working group chair who has participants who might be able to work on them? That's.

L

An interesting suggestion: I, don't I, don't know how I'm gonna make that request of my working group members well.

A

I can't because you know that I've run away from your work multiple times.

L

Yeah, which yeah, which one are you talking about, I, am a little wary of adding I think we have to be careful to make sure that what we put in these documents is advice and not hard requirements, and we have to be careful about the voice to make sure that it's actually helping and.

C

You know we get.

L

To the level of choosing tags for people or document names, or you know at some point, the volume of documentation is going to overcome the reader and that's where I think we need to cut it off. If not, we.

A

Obviously, have the current editor of the Dow in the line.

R

John Maddox I feel like there might need to be more attention paid towards the end of document. Lifetimes I was just going to look to see I'm still perfectly able to submit issues, a polar crest, so I'm TLS, one three which I met, would not be appreciated, so I wish and the contributing section still says. This is how you submit pull requests.

R

A

Absolutely have gotten two of those in the last three months on documents of mine, one of which was in off 48, but one which was already yeah.

R

A

R

Mean I think there's people from the open source key community are not used to think projects. That just say this is done and will not be looked at before five years from now. If ever so there needs to be a much much clearer thing of saying this is done.

R

We might take its you know smaller Brad ago here. Otherwise sorry.

A

Okay, so we only have six minutes left, but I want to make sure that Melissa who's at the end of the line is also the ad gets. The last word Nielson.

X

Over a University of Amsterdam analysis draft, it's mentioned that the get up API might possibly allow the backup of issues it should will, which maybe we consider death being a must and and being that in some.

A

Yeah, so the owners and says maybe is I saw the documentation there, I didn't, try it and so, like you know, if you say, I'm doing a backup and you never test it. That's not good, but I will test that.

A

H

E

H

So mark my comment on the tagging. Type of thing was because I was working with somebody trying to do a review to a gift of a draft, but because versions, weren't tagged in that way there wasn't now. Maybe the answer is that everybody should just use Martin's tools, okay, and so maybe that is the thing that we do just say that you know but but for people who are not or and maybe that's the best practice we just say everyone does that, but many other people are already creating their drafts out in their own repos.

H

And so now you go to charter, but.

A

Another best practices go back in history and add tags to the places where you have browse right. You.

H

Know the versions that clapping.

E

Santos and I think that Jonathan is right at the end of the end of process that we don't really pay enough attention to that right. His worry used to an RFC being published.

A

And then we all go whoopee and right.

E

But I got an issue open non-http to a few weeks ago, and it was great so I'm not going to close the the repo, because sometimes that feedback is fantastic and we're working on quick now and some of the there's some parallels there open the issue was was was a genuinely interesting thing to be considering in the context of quick as well and so having missed that. That would have been a bit of mistaken.

E

Of course, we're we're still collecting issues on the HTTP to HTTPS Bex well past the point that the the RFC was submitted. So I don't want to go that far but having having some process that perhaps checked when publication happened and sort of made sure there was a notice there. That says this has been published as RSA blah blah blah. But what.

B

To do and what to do with.

S

E

To do in that community.

S

Was still low so.

M

E

Can someone put that only issue to issue tracker please so we'd have to get that.

L

Mark nottingham, I'm gonna double down on martin's, come out there in the HTTP working group. We welcome issues on our already published rfcs. I I think that this this attitude that once it's an RFC we run away and we don't maintain it as ridiculous for live protocols from things that people still have questions about. You know people are right now abusing the errata mechanism. For that and I think we need to have a discussion in the ITF about the lifecycle of documents.

L

That's not this boss, but I really push back on the notion that the issues aren't welcome. Once an RFC is published.

C

Alyssa Cooper yeah I was gonna, get up and suggest people started filing issues in to Virata, so we there's definitely a piece of work to do there in the future. Not today, but I I fully agree with what Mark said. I don't fully agree with the last thing he said before, which is what I got in the queue in the first place: around naming, not labels. I, don't know, I have I'm ambivalent about the labels, but I do think in terms of the the document names and the repo repo names and the orb names.

C

I think that's a place where we could add clarity by having a policy around it and I think it's confusing for people, because there are lots of private repos out there and individual documents, and it's not totally clear because these things are not hosted on I.t org. This is like the one. This is the only thing we could do to make it more clear. Not the only thing, but a very obvious thing we could do is to try to establish the naming conventions, so I think that that's a useful thing to explore.

C

So as far as they kind of wrap up here, I think there's been fantastic discussion. I was not really anticipating it because.

A

C

I

A

At the end, so yeah I owe him about two, at least for three yeah yeah.

C

So that's great I hope we can carry it forward on the list if people want to start debating a charter, that would be a good thing to do. I also, don't think we need to wait until the next meeting necessarily to do a training, even if that's something that sounds like a desperate need, so that's something we can do as a as a conference call or you know the kind of thing you are suggesting Paul or something wider for the whole community.

C

Those things don't need to wait for the meeting, and then we can record them and point people to them in the future. So, let's think about getting some stuff done before a frog, yeah and.

A

Please do it on the mailing list. One of the things I worry about is that all sudden, this is gonna leak to the ietf main mailing list and.

C

Then everyone's gonna have the.

A

Same opinions again and such please, you know we had a lot of really good Mike line stuff here today. Please take a lot of that to the mailing list. If you have another draft like if you were like. Oh these drafts suck I. Have this other idea write drafts? That's fine! Since it's a boss, it's not like draft limited! You don't have to ask the chair because there isn't one. So please, let's keep this active I! Think that's a pretty juicy topic and thank you for coming. Oh.

S

A

T

Know they went around: where are they.

T

Oh excellent, like I, was.

L

T

T

J