W3C OpenActive Community Group, 14 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenActive W3C Community Group Meeting / 2022-09-14

Description

A public hangout for members of the OpenActive W3C Community Group.

Agenda: https://w3c.openactive.io/

For more information visit: https://www.openactive.io/w3c-community-group.html

A

Just welcome everyone new chair, my name is howard um and we're just spending this session. Looking at some of the ways of working for the w3c community group for open active, and so we have two documents which I'll link in the notes for this call, but I'll put one up on screen right now,.

B

Should also see the other thing that we do is uh usually is intros, so that people who aren't on screen um everyone knows who's on the call.

B

But I need to shortcut that it's it's it's debbie for everyone active nick from I'm in tim from the odi and howard from the alien.

A

Wow, so we're we're looking at the section on collaborate, collaboration and collaborative tools. We've talked about the open, active w3c community group, mailing list which we'll use to share information about the agendas and um notes of these meetings and the videos, and we just got on to the microsite, which is where we'll store all those things. So those those two are definitely still um useful.

A

You know valid uh forms of communication so for those that aren't here and for those, obviously for those that are, if you have ideas on the way these are run, um you know anything that could be changed or improved. Let us know by email or on the forum. um I want to say forum what what? What? What what's the best route nick.

B

Mailing list, or the slack channel, for um uh I guess, general stuff, but um there's w3c uh slack channel, which everyone's in uh called w3c uh community group chat. That's specifically around this group um yeah and there's. Obviously the most people are in you're in this group are, in slack.

A

Excellent, um so we went to the these conference call teleconferences um video comments which and the videos are recording, published, youtube um and there's a calendar.

A

So that's something I'll need to get on top of, but fortnightly rhythm, and that would be the plan to continue with that, as we move into phase five with the the aspects of open active that we want to take forward this this space, and so github is obviously where we manage the most issues and the specifications are managed there.

A

Google docs is there and anything else to say is slack's, probably the most commonly used is that right is that the most immediate.

B

It's it is the anything with slack. Is it as it says in this dock? Actually, it's not recorded so um discussions that involve specifications or anything in detail which should be really putting on the mailing list or on github. Most of that has actually gone on github, historically, um and sometimes when github isn't enough.

B

Google docs are used and there's a there's, a public google docs folder, which is available, um which has uh all of the uh all the things for the community group insider.

A

Okay uh and so debbie as a you know, as a third party should we say nick closely involved and open active all along, and it was me and tim as the odi now supporting it.

A

You know first for that external independent view. Do you feel this is the right level of interaction, collaboration.

C

um I have to be honest and say that I don't follow everything as closely as maybe I should, or maybe somebody else in our organization should consist some stuff that kind of goes um beyond my understanding or not not capabilities, but um I think one of the sessions was about um accessibility and stuff like that, um and that's not um really the right area for me to be involved in so it may be that, from an organizational perspective, depending on what the sessions about the individual may be different, that needs to be on that session, um the slack channel I've lost, I don't seem to have it anymore.

C

I did have it before um and yeah it's one. It is, I feel like it is one of those where there's a lot of places to go, but knowing how to get to the mall is a bit of a dark art.

A

That's really helpful.

A

I think you know we can. We can think about that and work out how to sign post people to the information they need at the time they need it direct route, um and I wonder, do you think that if the agendas were shared in advance that you would be able to connect the right people in your organization to the right sessions? If, um if something was coming up, say on accessibility um with advanced notice, you'd be able to.

C

A

C

I could I could certainly ask them. I can't I definitely can't make them yeah. I can certainly ask them if they feel they need to be involved. Yeah.

A

Great, so I think you know it's clear: we need to get the agendas out um and plan ahead and give people time to get the right bodies in the room as it were.

B

That's a good question actually and dairy. How many do you think two two weeks notice, a one week's notice for the agenda would be ideal as a thing to aim for.

C

I definitely think the more you can give people the better calendars are ridiculous. um I imagine everybody else is the same.

A

Yeah, I think my my ideal, bold words on on my first sessions. This chair is that you know we were trying to put a calendar of um of topics coming up. You know for the next six weeks or something like that. You know if we think that far ahead and try and paste thing, um obviously that's best laid plans. Isn't it so. But let's see how are we going being more um more proactive about the agenda.

A

Just make note.

A

And so this the slacktail, oh, is the. um Is that signup link in there uh nick still, or is that.

B

What's this one- and this isn't quite the right silent link as uh it should be, the self sign up link which is slack toy connective to. I am.

B

That one there so shout.

A

Excellent, um and so what we've mentioned, that for the open standards, development slack is, you know, isn't the ideal place, we want to point things move things to github where possible. So um I haven't scrolled down further in that document. Yet, oh it's here, so I will do just now um and the process for building census consensus.

A

Feels fairly, oh sorry, nick do you want to just talk through the um that the versioning of documents, yeah yeah, sure.

B

um Yes, this is the uh this. Is the process we've been using uh so far. We did change uh candidate specifications to candidate release at some point, which is why they're cr, cl2 etcetera, so there's naming differences there um from the original dock here, but um so I should say for everyone's benefit, this dockers um there's an original document that was written and then I'm subsequently updated. I think by myself in 2020, but I've left the um revisions in there for austerity, although we probably can accept changes and- and you.

C

B

Have this as a final version.

A

We can put a note in there that you know that we changed from candidate specification to candidate release or something like that just to explain that history, although if it's a google doc, it will have all the history.

B

Yeah exactly that we'll have the history and if we've got the call here where we've talked, I think the main thing is this document the changes in there, although they were de facto that had happened. I don't think we've had an opportunity on this call to go through the changes that make sense.

B

Probably why there, but now we've had the call um we can accept them, and um people can refer back to that conversation. um So the the idea here is the um uh there are there's an editor's draft, which is the current working versions. We have some.

B

um I know, there's um plans for this, but uh already but there's there's some challenges where we've got the editors drafts which currently are being used really to implement against, which is, um which is, is fine and working working well, but I think there's an opportunity to tighten um the specs up by just releasing and you know making the appropriate changes. There's a lot of discussion. That's gone into making lots of changes, but the specs themselves don't reflect those um in all cases.

B

um The test suite does and documentation on the website does that the specifications themselves don't so all implementations that have been happening have been basing um on the on the spec. But if there's a disagreement, they've been favoring documentation because the specs, as I mentioned, hasn't been um published in a long time. So we need to um ideally invest a little bit of time in just making sure the spec is is reflective of all the good work.

B

That's been done, refining and refining and refining over time to um to tighten things up, um which is uh yeah, so some some um stuff to go back to there and a lot of it's uh in there's a github backlog which should have everything in it um in terms of those um those changes, but um probably also worth a cross-check with the documentation at the end, to make sure that everything is is if, if everything's in there, and if there's a discrepancy that we have an opportunity to discuss that discrepancy um to make sure we can feedback on it.

B

um So so that's the so the editor's drafts which are which are out and available. um uh They are tagged. You know people can start implementing them um because they're suitably mature, it's just that they haven't finished the formal process. Yet the kind of releases are where we've got something that's a little bit more stable and that can be invented against specifically, and so we've got those at the moment. Cr 1, as it were, cr2 cr3.

B

Similarly, with cr3 cr3 itself is document, which is the cr3 spec document, combined with quite a few github issues, and you know 18 or something github issues which are amendments to cr3. So when people implement cr3, they are actually implementing cr3, plus the github issues.

B

um Because again we haven't gone through and updated that document yet to reflect those. um So we need to really publish that or republish that so everyone knows. What's what people have influenced against and then going forward? um We should be in a good place to um to eventually move that to 1.0. If we can get the last few implementations sorted um and then there's this idea of, um I think, in line with the w3c guidance for specifications which is outside of this document um having three or more specifications.

B

Sorry, implementations of the specifications before moving them to the final version, um so it stays in cr until we've got implementations enough that we're comfortable, but everyone's talked about it enough that we can move it to final, and at that point um yeah, that's that's kind of what it is and we move to the next version to the editor's draft, etc. Then works on the next version and onwards.

B

um Ideally we would be posting the published versions of our final to the w3c website and we've only, I think done, that with the 32.

B

So there's a bit of a backlog there of things to post to w3c website which we can do, or rather the chair can do that through the wwc um process.

B

So um it's just a bit of admin to catch up on basically around a lot of this stuff, um but yeah, I think the the processes is is written here is, um I think, is right. I think this is what we're doing. um Broadly. I think the challenge is really keeping the spec in step with.

B

um You know what what we're doing and making sure we've got resource to update that specification, so that it does reflect um the discussions that have been had and what's what's been agreed on this on. This set, of course,.

A

A

A

Yeah makes sense to me so far. I mean, let's see it in action um over weeks and months, yeah.

B

Oh, I should there's also this um editors, uh so obviously, with uh tim, outgoing we'll need to change some of the editors on some of the specs, I suspect um for the next versions, but as it says here, it's the edges, responsibility to manage the process of creating and building creating the changes and building the consensus around them. Within this forum, um anyone in the community can take on the responsibility of editing the specifications. So it's not a special, particularly special thing, because with this process being transparent, everything's in github, uh it doesn't matter who's.

B

The editor. uh The important thing is the process is followed and that's clear for everyone to see, um but obviously, with resources being constrained, it often falls on the odi to do the uh editing, but just because that's what the funding is um frankly, but uh often, but then, but that being said, uh there's um other people have done um uh being edited for other specs.

B

So um I'm, for example, I'd be happy to continue being joined, editor on the booking, spec um and- and you know, push that through to final, at least for this version, and then maybe someone else can pick it up for version two, but I feel like there's a you know, there's a good uh opportunity for completion of things that have been. You know in the air for a while that we can. We can take here.

A

Okay and I'm just going through the process for building consensus and.

A

Is there anything I mean we're just relatively small number on the call today, but is there anything about quorum or you know, like a minimum number of voices to to achieve consensus.

B

So the way we've been doing, it would be interesting to see there's a decision process which is actually in the charter. I'm not sure if it's oh superseded by anything in this document, so um I don't think it is so the charter might be a good place to look and I'll just pull that up on the screen.

B

So you can see um so the charter, I think, is still the charter, because I think we have to vote on it if we want to change the charter, and this process uh document sits on top of the charter um and the decision making process and the charter is here.

B

um The way that we've been so groups are free to decide how to make decisions.

B

um The way that we've been doing it practically on here is that we've been looking for consensus on on issues with the people on the calls and trying to make sure the right people turn up on the calls calls are recorded. So if someone doesn't agree with consensus- or you know they can and if they watch back, they can shout or if later on, they don't agree with consensus.

B

They can shout at any time until the document's finalized, and so there's a you know, obviously there's iteration meditation iteration and then, when we get to the finalization and um as we have done, um you'll see with the um recently with the customer accounts api we went through in detail. Everyone had an opportunity to um to reflect on it and feedback on it. um Who was interested in doing so um and uh and then uh yeah.

B

So consensus is then based on um everyone, who's, who's interested and available to to comment and we'll just try and get as many people as we can to um to look at that stuff where, um where it's relevant um so there's a if substantial disagreements remain so that so, everyone tries to get to consensus um and that's what we've been doing as we've been going through. um Whoever chairs the call uh you know uh will would do that um and then, if there's a disagreement, that remains. The group needs to decide um uh and they're.

B

Gonna need to decide an issue in order to make progress. Committees can choose an alternative uh that had substantial support with a vote if necessary. um So there is, there is provision for forking in here. Obviously that would be a crazy thing for open active to do to the floor, because open source projects do. But if there's individuals that really disagree with the choice taken after consensus and a vote, then they can take the standard in a new direction brand. It's something different and do something else with it.

B

um That's never happened um with this group because usually there's a really good reason for someone objecting to something, and it's just that we've not thought about it um as uh as this happened with uh with with debbie, actually has um witnessed this quite a few times when someone's gone. Oh, what about this? You go oh good point um and then change things.

B

um So uh so this is. This is allowed referred to blocking with the goal of that implementation. Experience can form which spec is ultimately chosen by the group to move ahead with. So basically, that's like the way that would probably work, I mean you could badge it fully as something other than open active or you could. You know badge it as I don't know a and b or something, and then let people make their own minds up and keep it within the tent.

A

But that yeah, that seems to me the the spirit of that that you know if you disagree.

A

You know there isn't a decision, then okay prove it. You know if, if that fork is a better route, sure feel the community um and that doesn't that feels like a trial by combat kind of situation, where at least you can in the real world, see if that, if that is a better solution that that doesn't it shouldn't have to mean you know going off and calling it something else. um Yes is that experimental this way is going to work for us I mean yeah.

A

I can see that I can see the challenge there, but, um okay I'll uh sorry,.

B

Yeah yeah yeah, so um uh any decisions uh reached any meeting attentive and should be recorded in a github issue for the groups to use github or otherwise on the group's mailing list. So I think that's what we talked about earlier. These are the two places where decisions are recorded.

B

um Any group participant may object to a decision reached at an online or in-person meeting within seven days of publication of the decision, provided that they include clear technical reasons for the objection. So this is that you know not. Everyone can attend every meeting, so there's a period of time where people can um object to things.

B

We've actually been much more lacks with that rule than the seven-day cut-off periods, if someone's missed a meeting, and they mention the problem later because, as I mentioned, that we've now, we've never really had any friction for stuff on these calls, because it tends to be obvious, based on someone's mentioned, something that no one's thought of yet or whatever.

B

And so chairs will facilitate discussion to resolve the objection. According to the decision process, which is this process, the chair's responsibility to ensure that the decision process is fair respects the consensus of the community group and does not unreasonably favor or discriminate against any group in particular, or their employer.

A

Fair enough um well I'll, I will read the rest of that document, uh but I think, for you know common sense. It feels like the right approach.

A

Happy to carry on like that, um I guess.

A

What else is in that um under the under that document is for building consensus, we're about there. I mean it's proposing changes in this template at the end, so that all very makes sense. Yeah, yeah.

B

I was just going to point out that if we did want to bend the chart, so there's actually a process to do that in here. I think it's something 30-day vote um so yeah just um yeah there's some documents like this and standards that have already been finalized um or version that it's you know, um changes to the dock itself are not the ideal way of doing it without going through the due process.

B

uh That's yeah.

A

Sorry, you were saying well, that was was, that was for the charter, not the um not for the community group document.

B

Oh yes, sorry for the charter. That's right! The charter, the charter itself, rather than the community document. Exactly yes, yes, yes, this.

A

B

A

Yeah, so just an effective reminder, I guess for people who are newer to the thing if they do see this video, that that's what we're all about, so I um probably just used the last few minutes. um If deb is there to, I guess call on ask for any priority areas or any any topics. You know if we're looking ahead at agendas for coming months, what are there any areas that you'd like to see focused on in these conversations or any particular areas in the github issues? Backlogs anything like that.

C

I don't personally have anything, but I would imagine, there's probably other people that have got opinions that are not here today.

B

Okay, yeah, it would be good to ask that question and as an agenda item people know it's. uh I can't I can say that there are from implementations that are currently live. uh There are um the getting the getting the specs finalized as we talked about. um You know that that would be that'd be quite helpful for um tidying up.

B

If you like um what we've got before we um well not before we do other things, because um there are some, uh uh I guess some some minor issues that are left, I think around um around the booking spec, maybe and on. I think the customer accounts api, but yeah again. I think that just needs to be transferred into a formal document, so um so yeah. So I think there's just from from my perspective at least there's there's some good uh admin to do.

B

um I think and- and I think that uh yeah putting a wider call out would be the thing to do for yeah priorities, otherwise,.

A

Excellent I'll do that.

A

A

Other than that, um I suppose around tim anything you want, you prioritized or raised a decision and nope, don't don't think so and other than what we discussed so there's something some admin ty. You know getting the call out um getting the agendas out in advance.

A

um I suppose once we get those ideas and priorities back in getting the recordings out, but nick anything else, you know: what's your top three things to get signed off at these sessions.

B

um For me, it's the it's the finishing the specs, I think, is the thing so there's there are. If we go into the backlog of what's left, to get those specs to um you know the next. uh You know point iteration or finalization. There are topics to discuss which haven't yet been, or um we just need to just need to kind of draw a line under maybe there's you know a good call where we can go through like a batch of them and say right. This one has been discussed.

B

It looks like the consensus is this: are we all happy with that? Great next and just kind of rapidly, um you know move some of those things through to the kind of the final, the final stage, um there's nothing that's blocking. As far as I'm aware any current implementation, because um current implementations aren't um they're just using what, as I mentioned, what's in the documentation, so um it would be good to get the specs back on to the point where they could block the document.

B

The process right because they're being used as the um the point of truth rather than the documentation.

A

A

A

That's great they're, really helpful and um but obviously we've got the steering committee tomorrow for the first time in a little while so be interested to see. You know what emerges if anything emerges there on priorities, but I don't imagine anything dramatic. It's going to change just like that. So um that's really helpful and we'll probably call it there. I think it's there's nothing. Nothing else to cover today.

A

You know it was a my first session, so just getting the groups all right, cheers everyone and uh we'll get gendered out for future for future meetings.

B

Great thanks guys.