 Yes, well done everyone for coming at 9 o'clock on a Sunday morning, I'm really quite impressed. I'm going to sit down for this because I'm really tired and sick and generally have no energy, so I apologize if you can't see me or something. So my name is Greg Zuckleff, I am the Community Lead for the Foreman Project. I'm not going to talk about Foreman today, if you want to know about that, come and see us at our booth. What I'm going to talk about is what I want to do is to get you guys through the talking because as I said, I'm all tired and sick. So the idea here is, I've not been doing this for that long, for about a year and a half. I was a developer and assistant admin before that, this is not my core strength shall we say. And there are situations that come up in our community that I think are interesting, I think they're not unique to us, I think they're worth talking about, maybe I can live from you guys, we can live from each other, maybe we can have a little discussion. Let me start by talking about what I mean by loops, possibly this is a term that people want to clarify. I'm a fan of GTD, Getting Things Done, and in that book they define a loop as this, anything pulling at our attention does not belong where it is, the way it is. Or in the case of virtual communities, things like undecided RFCs, unfinished discussions, unfinished reviews, PRs that are open, stuff that is not done yet, stuff we have started but we have not finished. And I don't know about you guys, we have a lot of this in our community. We have a lot of this in our community. And so I'm going to pick a few examples that maybe, hopefully I've got enough content even if you guys just basically want to sleep, but even if you don't know, we'll be fine. So I'm going to start with a conclusion because that's fun. So as I said, I don't think this is unique to form and I think a lot of online communities and a lot of face-to-face communities have these issues, although I think face-to-face it's easier. There's not going to be a one size fits all solution here. If there were, we'd all be using it. There are obviously as many governance policies to open source projects and other projects as there are projects pretty much. So there's stuff we can learn from each other, stuff we can try. But this is the community track, right? We're all community people. So maybe we can share some knowledge and maybe I can learn from you guys and take some things away that we can try in our community and maybe you guys can all do the same. So let me start with a quick disclaimer. I've taken all the names out of these scenarios that have come up in our community. However, if you're familiar with the foreman, you're probably still going to be able to figure out who we're talking about. It's just the way it is. But I want to be clear here, no one is at fault. I am not blaming anyone other than the systems that we have. Everybody has the best interest of our project at heart. I firmly believe that, but I think we can improve the systems. So that's where I'm interested in. I am not about pointing fingers at people. So let's start with, I've got two main examples. Since I've probably only got about 15 minutes left technically. I've got two main examples I want to talk about and maybe you can give me some ideas how you might handle the situation. The first one is to do with RFCs or Request for Comments in terminology. So change proposals. Things we want to change about how the project works. Not little patches, not bug fixes, but significant amounts of effort that go into changing the direction of the project potentially. And I'm really interested to hear how other people handle this because we had a discussion probably six months ago, something like that, where we were really struggling. We were thinking about how to have these discussions. Up until this point they were happening on our development mailing list. And that's fine. But I don't know whether you guys get the same problem. But a development mailing list has a tendency to just die out. You get really good participation for maybe two weeks. And then it just kind of trails off, right? It trails into nothing. And what's the situation here? Worse, in my opinion, it's difficult to track, and this is specific to RFCs, it's difficult to track how the proposal has been altered over time. Someone can write a proposal saying, I think we should do things like this. A few other people will make very, very good comments. So you alter the proposal, you update the proposal, you say, okay, well, now we're going to do it like this because of these comments. And so forth. So there's an iterative process when it comes to RFCs. But mailing lists are not good at tracking this. So we started to have a discussion about where we should do this. And we came to the conclusion that we could do it on the mailing list, we could keep it where it is and just accept those problems. We could move it to the Wiki. We do have a Wiki. Or we could move it, we could actually use like some kind of GitHub or something like that. All of our stuff's on GitHub anyway. So that's got nice tracking of history. It's got nice tracking of how a proposal has altered over time. Maybe that would work. And we did indeed decide to go for an RFC repo. But now we sit here six months later, and I'm not sure we're any better off. We've only moved the problem. Discussions are still tailing off into nothingness. There's no decision making happening. And I'm really curious to hear from people how they handle that final close down of a discussion. How do you decide when something is done? And in the case of RFCs, who gets the decision about when do you accept an RFC or when do you reject an RFC? Does anyone want to jump in on this? At least from my experience in median discussion and when somebody starts doing it. Like, there's something like this. And they last around forever. And somebody says, hey, I like that. I'll do it. And somebody, but me, somebody with the energy, there's a different energy level in discussing and throwing out their beers and actually getting... Right, right, right. And you need that energy to condense into somebody's hands. Right, so for the video then I guess since I've got the mic. That's the case of it's done when someone starts doing it, which is fair and I think is what happens with our community as well right now. The problem I have with that is that the whole idea of... And this is great for discussions about technical problems that need solving. But when it comes to RFCs, the idea is always that you should probably accept the RFC first and then code it. At least that was what was in my head. Maybe I'm being naive. But that was kind of my intention and that is not what's happening. What's actually happening is the RFCs get merged when the code has been written and merged as well. It's a de facto acceptance, right, because we've already done the work so now we just merge the RFC as well. So that was the thing. Anyone else? So in the Librom project we had an engineering steering committee. Everybody could join that, but you have to be in a weekly telephone call and when there's something that you want to discuss and it's not really clear what you want to do, then you bring it over there and discuss it there and then we do a decision or say, okay, it's not final yet. Come back in a month and look at this point. So there's not much going on there, but it's probably so large, normally people just merge the stuff. But if there's something really questionable, we say, okay, there's something back, something that's committed, which is not acceptable, then we just cancel there. Cool, cool. So for the video that's a technical council kind of approach where you have a group of people who get to make the decision, right? So I thought about this and I actually spent a lot of time last FOSSTEM talking with our community about whether we should do this and most people were in favour of it and I eventually backed off from suggesting it more broadly to the project because it felt really heavy for us. We're a lot smaller than something like Libra Office, right? I don't know. I mean, we approach the 40 people who have regular committers and we have a lot of two or three time committers where people come in and they are. Yeah, I guess 10. It's not that many people who are employed who are going to be brought into the project. That's true, that's true. So maybe that would work. And do you have a document that describes how you joined that committee and how that works and so on? Weekly and on over who is involved with all the stuff and everybody can join. Instead of calling it all something that's private. Of course, of course, of course. And everything that's written to be for many of us after that. So that could work. Right, right, okay. So, right, yeah, just quickly because obviously I've got the mic. So what, 40 contributors, regular contributors you reckon, and that works pretty well. Summarized, okay, I think we're probably about 20 regular contributors. So maybe that would work for us, actually, that would be quite good. Yeah. Okay, so, yeah. Yeah, so this is something, so, sorry, yeah, for the video. So it's a voting process, minimum two weeks before that's used and then the author gets to trigger it. Great. I thought about that as well and that's something I would probably like to see more than a technical counsel, I guess, for us. But I find if you vote on everything, it's really divisive after a while. I don't know if anyone else has seen that happen, right? If you get too many votes that are close to 50-50, and I can't think where I've seen that in the world recently, it gets really divisive in your community, right? If it's almost unanimous, then it was kind of happening anyway, but yeah, it's tricky. Does anyone see that on the page of the RFC votes because they tend to solve that during the discussion here? Yeah. Do you find there's a problem getting the... What's the right way to put it? So the quieter members of the community to jump in on that. Do they participate in the vote at least? Is it an anonymous vote? No. Yeah, okay, so... It depends. If the core contributors is a relatively small team, but you've got what they call climate by the ability to vote, if you've made a commitment to be able to be... Right. ...particularly the... ...intentional issues, to make some significant issues, you'll suddenly see a lot of people come out the good way. Right, yeah. It's not a democracy, right? It's a meritocracy. People have more weight. So, yeah, I mean, that's definitely something we're thinking about. I was wary of voting because of that kind of issue, but... It does have the other issues. I like the idea that the author gets to choose when, because one of the things we put into our RFC process was the idea of trying to drive consensus and that the author should spend time talking to people and try and bring it. And if he feels he's done enough of that, then he can trigger that vote, right? So, that's cool. All right, so, let's work it out. Let me move on to my second example. Thanks, guys, for your contribution style. That's really useful. Let me move on to my second one. This is what happens when discussions potentially go a little bit wrong. Not wrong exactly, but a little bit, shall we say... Yeah, head to head. A little bit contentious, right? So, let me give you the scenario that happened. We had a proposal, and this was before we did the RFC thing. We had a proposal that came into the mailing list. And in particular, it was to drop a dependency, an OS that we built packages for that was getting to be a problem. And we had pretty good discussion on that thread for a couple of weeks, and then the thread goes nice and quiet, but nothing happened, right? Nobody really said, are we done here? Is this finished? No action was taken. But then suddenly, after about two months of nothing at all on the thread, without pretty much any warning, the thing that was proposed got done. The OS was dropped, the packages were taken out of the system, and then a whole group of the community just went, ah, hang on, we weren't done here. Now, you can't fault either side on this one, right? On the one hand, the discussion was looking like it was moving towards dropping that OS anyway, and there was a nice long period of time, and then that OS got dropped. So it looks like proper process, but then the other side of the community was like, well, we never actually concluded it, and we were actually kind of relying on that. And you kind of want to say, well, where were you for the last two months? Which we did. But nonetheless, they actually did have a point. There was a pretty significant chunk of the community that was using that OS, and we probably needed to give them a little bit, the user community rather than the dev community, of course, and we probably wanted to give them a little bit more warning and talk about how to migrate up to the next version of the OS and make sure that you can move all your data across and so on. And there was a fair amount of upset about that, I would say. It never got ridiculously out of hand. We didn't have people rage-quitting or anything like that. But it did make a mess, and we ended up with one of the plugins for the form and deciding to unofficially create packages for one release just so that they could give their users a little bit more time, which is a fair solution, but not ideal. So my question to the room for this one is then, we've kind of covered it for the ROC, but it's a little bit different when it comes to a situation like this. So when is the discussion done? I guess we've kind of covered that, and that's fine, because I think I've only got about five minutes left anyway. Ten minutes left. But here's a different question for you then. How do we handle the differing expectations of groups when you get into situations like this? Does anyone have experience of hitting a situation like this where you've got two groups who really thought things were going in a different direction and then suddenly find that someone has to lose out? Was it ever made clear on any kind of notice in the form of community that a conclusion had been made and there was a period, a race period? No, that's true. The OS was dropped without warning after about two months. The person who raised the original request obviously felt that the discussion had reached the natural conclusion and that it was therefore okay to go ahead. It is fair to say the discussion was definitely in favour of dropping it at that point. In some ways you can't fault him, but I agree it would have been nice to have a grace period. I think, especially when we're working on the internet where we're not seeing people face to face in an office scenario. If you're in an office and you say, okay, I think we've never seen anything for two months, let's take this as the official stand before the grace period of two weeks or whatever a month, because I think the worst thing is not knowing that someone is about to happen or you're not expecting it. When there's an expectation and you've actually declared that, then no one can default you as out of sight because you've been clear about your intentions. Yeah, and I agree, and that would be my only criticism of that side of the debate, that it was done without warning. It might be interesting, though, I haven't seen it done yet, to redefine the grace period, which I like as an idea, not just as, if you don't mind, this is the status quo of the discussion, if you don't like it, keep discussing it, but this is the status quo of the discussion, this is what's going to happen, and if you don't like it, say what is your use case, so it could be taken into consideration where that thing happened. Sure, sure, so just restating the current position every now and then, every so often. Make an opening for, like, mitigating... Yeah, sure, sure, sure. So adding that onto the grace period notice is what you're basically saying, is, yeah, jump in if you're not done here. Very difficult, I would say. We have a developer's mailing list, and we pretty much assume that's the source of discussions. Now, the RFC repo was a new thing we added this year to try that out, so have we fragmented it? Probably. But I try and reach out to people I think should be involved in the community, but I make it as a personal effort, rather than we don't really have any systems for that in place, right? Most of the time, the people I expect to comment on things do comment on things. I've rarely seen a situation where someone I would consider a stakeholder in a discussion is just absent completely. So there are situations, I think, that occur because some people don't like the RFC repo and would prefer not to use it, so that becomes an issue because they'd rather see all of that happen on the mailing list. But apart from that fragmentation, most people are involved and engaged. I don't worry. So you make an interesting point, actually, about using other tooling, and that's something I wanted to bring up. So I don't know whether it's the same tool, but I was looking at Lumio, which Diaz Borra Foundation uses for their decision-making, and I like the idea, but the problem is it's more fragmentation, right? It's more places in which you can have a discussion, and I don't know if it's the same tool, but I don't know if it's the same tool. It's more fragmentation, right? It's more places in which you can have a discussion, and I worry about that a lot. If I'm already seeing problems with some people refusing to use the RFC repo because they'd rather keep it to the mailing list, this isn't going to make it better. And that's, you know... You can see the current status. Right, exactly. You would have both, I guess, like a general discussion in that thing or in the mailing list and specific... I'm definitely looking into some kind of at least when people post RFCs and automatic mail going to the dev mailing list so that people are aware of it. Yeah, you can have general discussion in both places, I guess. It's a really nasty one. What's the name of the tool? It was called Lumio, was the one I was looking at. L-O-O-M-I-O. I've seen a few projects using it, and it looks interesting, but, yeah. So, I hope... Yeah, sure. You were talking about the expectations of the actual development or the outcome, but what about the expectations of the decision-making itself? Are they clear? I think that's an important question. So, what I'm trying to say is is there a clear way that someone makes a decision or a decision is resolved? So, if a technical decision is made and it's not in my favor, it didn't happen in a process or the way that it's transparent that I understand. So, for example, most projects have to be a bit of a dictator model where it's like, if something does not get resolved, there's a disguise, and we all know that it is going to make a final call because that is clear ahead of time that that also does frustration. So, you make a good point. We did partially cover it. I guess I didn't put it as clearly as that. So, it's a good model for finishing a discussion, but the discussion itself is usually pretty good, pretty what's the word I want? Friendly? No, that's not quite the right word. Courteous? Yeah, constructive. People don't get personal on our mailing list. It's nice, it's clear, and we do try and take account of people's viewpoints. It usually goes pretty well. The problem is when is it finished? That's the bit we're really struggling with most of the time, and I guess that's the problem. That is the problem. That's what I'm trying to get to. How do we actually solve that problem? Because really, as far as I can see it, there are three methods which we've mostly covered. Which is the technical council voting or some third-party tooling like Lumia, which is really just a vote anyway. Those all have their consequences. The question is which consequences are we happiest with. But then I have to have one more discussion on our dev mailing list about which thing to do, and then hopefully we can be done with it. Do you have a timeline for the discussion? How long does it take? You have to take a decision and do that. Some decisions obviously have that built in. If you're talking about what needs to happen before the next release, we have time-based releases, so therefore there is a deadline for when code freeze will happen and so on. Other things? No, the discussion is done when it's done. Because based on your experience you know approximately when is the time for discussion? Yeah, it's about two weeks, right? Just to put an end to the discussion on the deadline. So that by that time... But you come back to Laura's point, right? If you put a deadline in, you still have to work out how you're going to take a decision at that deadline, and that's the bit we're missing. Is someone going to make a decision? Is it going to be a vote? Are we going to take it to the technical council? How do we actually solve that problem? It feels to me having... and thanks for everyone's input, I guess we're just about running out of time, so I'm going to wrap it up there. So it feels to me like probably the technical council might work better than I first thought. It felt very heavy to me initially, but if it works well for 40 contributors it probably would work well for 20 contributors. It's the same order of magnitude, right? So maybe that's something we should look at again. I really feel votes can be divisive, but hey, maybe PHP has got someone to teach me there. Maybe it's not as bad as I think. Anyway, thank you all very much for your input. It's been lovely hearing your opinions. I'm happy to continue the discussions. We have a booth down in the K Building, so come find us. This is the various links if you want to find me on the forum projects. Thank you very much.