 And now, for our dear people today, this is, I don't want to be actually the last one to do this, but this is Bertrand who will pronounce the last name, sorry, I'm very tired. And he will talk to us about A.C. Ernest, who is making open source projects. At work I'm installing 30 people to hold this Bertrand set to my last name and set that I did back then. I'm from the French-speaking part of Switzerland. I work for Adobe in Basel, Switzerland. And I'm also on the board of directors of the Apache Software Foundation. So I have these two hats. So Apache is where we do very open source stuff. And that's where I learned to do that. I've been Apache for many years, I've set theory. And involved in lots of community stuff. Incubator, old directories, several projects. And then trying to bring some of that wisdom into the company. Adobe is like 14,000, 15,000 people. Let's see, for me, it's a really big thing. And as you probably know, the corporate network is often not as efficient as in terms of project management and how we collaborate. And that's what we're going to discuss now. Secrets decision making, as in making decisions without interrupting people. Which is something that we do very well in lots of open source projects. This is based on two serious things that I did. This was a kind of provocative one. I will not attend your meeting. I'm an open source person. That I did a few years ago. And what I'm just speaking about today is kind of the more politically correct version of the thing. I will not attend your meeting because we could do that in sequence. And I have two articles on the web about that open source competition. The most recent one. So you can read about that later. The fun thing with this Q&A thing is that we're not sure if the people on this side of the room could still arrive. If they're really here for this one. Or they cannot queue for the next one. I'll be extra careful to try to convince you guys. In case you're in this situation. So this is the gist of it. Open source is about remote software. If you're working in a lot of open source projects all over the place. People from different time zones, different cultures, different model forms. They have a lot in lots of projects. Apache is very egalitarian. We don't want buses in our projects. There are other models which work for other source approaches. That speak in Apache in a way. And actually they make lots of decisions. If you look at software, software is built with decisions. What tools do you use? How do you structure this model? We're going to work on that. We're making constant decisions all over the place. And it happens in open source projects without meetings. Most of our projects, they don't have a meeting. If we have a meeting, it's for socializing and for having breaks. But for work, for doing the actual work, we do very seldom have meetings. And if we can keep the process efficient and fun, that's much better. We know that you do your best work when you're having fun. The process, even if it's in a big company, should be fun. If you want people to stay around and do a little good job. We often call that in servers where we share neurons. Putting people's neurons together in the most efficient way. Do something, something. So what do I mean exactly by a synchronous decision-making? I'm not the psychology store anything. So I hope I'm not saying too stupid things. That's from a pragmatic point of view. How do you get to a decision, especially in a group? So first, you need brainstorm. You need to evaluate what could we do. It's good to be crazy at this time. Don't be limited by reality or by economics or whatever. Have crazy ideas. Then you need to kind of relate that to the reality. What's actually possible or remotely possible? So this is the second phase when you define the options. Okay, we have all these crazy ideas. And concretely, we have these four or five. If you can reduce to maximum six, seven options, that's good. I like to have three, four, if that's possible. Then you need to build consensus in these options. If you're in a group, you have different options. You need to, you know, get a common understanding and what's possible and what are we going to? What are the actually valid options on which we need to decide? Then the last step is the decision. None of this in the abstract requires you to be present in the same room or in the same channel or on the phone. You know, unless in some cases, in some organizations, you have a former requirement that the decision is to be made by voting in person. We have that in Switzerland, voting in some countries not all people still vote by hand on the village square. That's kind of an old thing, but still. But some former organizations require you to be, you know, in the sequence of voting. But, you know, in the software group, it's not the case. There's no specific reason to do that. And I think you really need only two families of tools to do that. I'm not going to talk about specific tools. It's kind of, you know, tools, roles. And I see two tools that we need to do that. One is a shared asynchronous communications channel where you can talk to, you know, kind of broadcast ideas. And then you need to go to a more structured place where you discuss a specific idea or a specific decision or a specific brainstorming and so on. And this is what I call just a case management tool. You can very much do that. This is a marine radio where you can, you know, if you call on channel 16, everybody gives you and then you can switch to different channels to have a more specific discussion. It's similar to mailing list, the way it works, or a slack with many channels and whatever you want. But you can very much do that with radio. And then you can very much use a case management tool with index cards and small drawers. It would work. And sometimes it's a good way if you're in a room together, like if we did need to make decisions with this big group today, we would have whiteboards for the communications and then smaller whiteboards for the case management or the details. So this doesn't necessarily require software. Of course, when you use software, it's more convenient. But when I'm getting at principles, exactly which tools you use doesn't matter. And again, the meetings are not really required. Doing it asynchronously gives you more time to think. And if English is not your primary language and you're working in English, it's good to have time to think. Maybe you need a bit more time to understand what the other people are saying. And as much as you're inviting them and when someone is speaking at a fixed rhythm or very fast or whatever. So there are many advantages in working asynchronously besides just not interrupting people who should take the most important thing. So why do I think you need to do that? My father was a carpenter and he had a workshop and we had a flat department on top of the workshop. Sometimes he was laid for lunch because he was gluing things. You know, you're gluing a chair and you're starting to glue it, you cannot interrupt. If you interrupt, it's ruined. Your chair will not work. So, you know, Daddy was coming a bit later for lunch because he was gluing things. And when you're working on a maker's schedule, it's really, you know, and we know today that if you're a software developer, you get in its own and if you're interrupted, it's over. You know, you need maybe two hours to go back to what you're doing. And this is what Paul Graham, I'm here to talk to you by Paul Graham, calls that maker's schedule and manager's schedule. On a maker's schedule, the interruptions are very expensive. On a manager's schedule, at least if your schedule, weekly schedule is made of one hour slots, if you are, if you are, one more meeting is one more slot. It's not much. If you're a developer, the one hour meeting in the middle of the afternoon will very likely bring you up. You're still being able to do things towards the kind of people that you need. So this is very important. So meetings are very expensive. If people had to put coins in a machine when they do a meeting, otherwise the meeting would stop. They would realize how expensive a meeting actually is. And you shouldn't take them lightly. It's great if you can have meetings, but you have to realize there they come. And we also always joke about, you know, if you go on YouTube, you'll find tons of videos about the failed meetings. I think the worst ones are the phone conferences with 18 people, where you're like, oh, that doesn't work. We know that. So it should be better. And the open source world does better. So we can figure out how to do that. So how, let's get to the end of this. I don't know how you do that. So I'm just, I'm saying you just need these two kind of abstract tools, the shared communications channel and the case management tool. And then how do you use them for different phases of the decision? The brainstorming will happen on the shared communications channel. You know, it's messy. The discussions are not, maybe not well organized. It's many years old, Slack channel or whatever, or Marine radio. It's not extremely efficient in terms of being structured, but you can at least exchange ideas. And then at some point, when you go to the options phase, you might need to move to the case management tool already to have a more structured discussion. This is the discussion about the options of the decisions that we're working towards. In software, you can very much do that in an issue track decision. You could use, you know, any one, you like, zero or whatever, to do that. And in my groups, we tend to do that. We tend to use or get issues, whatever. Already at the options phase, you click the ticket just to discuss the options. It gives you a better, you know, better place. It has a URL. You can bring people to it easily. It's much more efficient than an email track. So part of the trick is learning to juggle these tools and switch, you know, between the various tools and the right part. Then when you get to the consensus, we talk more about how consensus works. Consensus is already starting to be in a smaller scope, or maybe also structured. So I would probably do most of the consensus building in the case of... But if it's... If it's easy, maybe you do it on the main list or on the channel that you're in. And then the decision, I think it's really good to do the decision in the case of two. So if you're working with tickets, you have one ticket for the decision. This is the decision that we made. And you have links to the, you know, to the various arguments or the prototypes and the link to that. Then people can go back to this decision later and understand it. We don't have to re-explain. If you give them the URL, people will ask, hey, why did you do it like that? I gave you the URL. Go look. Maybe then, later, you come with more questions. But at least you have all the faces. From a big file of doing everything in the tracker in terms of making decisions. But there are different styles. You will see that in the example. Interestingly, on the left, is the Swiss government. Swiss government, the Switzerland is governed by seven people for the federal council. And they have to agree, which is already making lots of decisions. They have a meeting every week, in-person meeting, which lasts maybe three hours. And they take 80 decisions every week about it. So that's a lot in three hours. On the right, I'm talking about the patches. So I'm on the Apache Board of Directors. We have a monthly, four-week meeting, which lasts about two hours. And we take also about 80 decisions, two hours. Why? It's not a good Virginia system. It's because most of the meeting is prepared in advance. Most of these decisions are actually done in advance, using these synchronous decision-making techniques. And then at the meeting, we might just ratify the discussions. The Swiss government works on our actual idea. Here is just about consensus. And the Swiss Federal Council says, we decide by consensus if we can. And if we can't, we do a vote. So what's important is having the consensus. If it's obvious, we don't even vote. Sometimes when people join a Apache project and start voting for everything, it's not going to do that. If you have consensus, it's fine. And then if you have difficulty getting consensus, then the vote might be useful. And it's fair. It has no deterministic rules. So, okay, maybe you didn't win, but it was done because it was good. So, trustingly, these two bodies work three similarly for doing that. Let me give you a few practical examples of how this works. And you see that the exact tools vary. But the principles are the same. This is something from the Apache-Cordova project. Cordova is a tool kit for winning mobile applications. It doesn't matter if you're just looking at, you know, how they collaborate. What is Cordova discussed, which is just a GitHub repository. And they use it to discuss new things that they might do new features that they might add to their software. So, making decisions about doing these features, these features or not. And they have defined a very simple process. They start with a ticket. If you think, oh, I would do 3D audio on Cordova, you create a ticket, say, oh, I would like to do that. You explain how it works and your discussion. This ticket. And if people agree, if there's consensus about going to the next step, then you create a file that describes your project and this gets refined in the options and destiny-making process. So, you start with tickets and they continue with the file. That's edited for collaborating. This is Apache-Cordova project where I'm from the activity of Apache-Cordova foundation and we do kind of the opposite. We start, if we want to do something, we start by discussing it on a mailing list. So, an unstructured, often messy, somewhat messy discussion. Then, when it gets to a more complete stage, we move to the tracker and we do a, this is Jira. We do Jira ticket where we discuss the details. So, again, various tools but always the same concept of a kind of broadcast or semi-broadcast communications channel and then a more structured case management where you, you know, we do the details and this is going back to my examples of the Swiss government and the Apache-Cordova directors. Again, we see quite different tools. So, I'm not part of the Swiss government. But I actually wrote software that they used to, they used to do the agenda for the meeting. So, I know where it is for the information for that and you have good. This was done in the client point. It was exotic to do software in Java. Long time ago. So, the way we do it in the Apache-Cordova directors, the case management tool that we use is extremely simple. It's one text file. Call me. We have one text file which is structured. It's a simple structure that we have defined. And here you see, for example, the discussion of approving the report, the decision of approving the report of the presentation project. And you have a small discussion in comments. So, it's coming from our series. We have the discussion of approving the report of the project. And it's just some structured text in the text file which is managing its version for external reasons in the, you know, source code management system. Everybody can add in, you know, step on each other. Those, we are now approving that word for whimsy makes a question. But at the core, it's just that. So, very simple tool, just a text file with some conventions in source code management. The Swiss government does it a different way. They have paper lists for the meeting which are color coded. So, I'm not sure about exactly what color means what. But, for example, the orange list has uncontested items. So, the items on which they agree, they know before the meeting that they're going to agree to follow. So, in the meeting, the chairman just said, guys, maybe you don't understand guys, they don't. Their excellence is a lot more important. And then he says, are you okay to approve items one, two, ten? Very quickly done. So, maybe after 15 minutes, they have already made 50 formal decisions. Because those, we are done in advance using the AC process we're making. And then they have a glue list where they think, oh, there might be some discussion. So, we cannot just take the items like that when you open a small discussion. When we're confident we will get to them in the meeting. So, another 20, 30 discussions are made quickly. And then you get to the final, maybe three, you know, where, when you know there's going to be a final. So, then you have some space left in the meeting for that. So, it's a very efficient organization built on very simple tools, color coded paper lists. And it works for them for governments of, you know, very easy people and very efficient in terms of making good decisions. So, I think this really shows that this works. It's really, I think, how open source projects operate and how successful. By making all these decisions in a way that's traceable, documented, fair and without interrupting people. So, I think this really shows that this works. It's really, I think, without interrupting people. Which is very important if you're working on a maker's schedule as software developers. So, again, I think it's important to avoid focusing too much on the tools. As geeks, we often, you know, we really started on the discussion about tools and we found it like that. I don't think it really matters here. But kind of going back to the basics of what in the abstract, what are the roles, what are the exact functions of these tools that we need. So, I think the open source projects demonstrate our demonstration. That is really good. I have some more reading links on the slides. So, you can do a pile of pictures of the links in the in-coordinated services or two more articles or videos. So, my takeaway would be that I think this works only. So, if you work in open source projects it's important to be aware of these things and try to steer the team to really work like that. But it can also work in other circles like in a company or big company or small one. And for other topics this is the one that does the software now I think. And you see the exact techniques. I think it's very interesting. Thank you. You have to find we know that forcing people usually doesn't work. So, you have to find incentives for the people to use the tools in the right way. And I think the good incentive is making an example by using them yourself and having good results. I think that's a great way to work with them. Then you might have the problem of people using the tools in the right way. Or you might have the problem of people being shy or being afraid of large mailing lists and things like that. So, it's a I would say it's a constant challenge. But for me the best way is to show them make good examples and expose them. Have an internal blog post or whatever. Thank you. Thank you very much. So, do you mean consensus? So, consensus is not equal to human dignity. Do we agree on that? Consensus is widespread agreement. Yes. You would find my name in the board minutes by the one who has abstained from some decisions or both didn't know. And it can be a bit embarrassing. So, you have to accept that your idea might be the minority one. I would say that if you can reach consensus it's much better. Sometimes it's obvious sometimes it's kind of natural consensus where people say okay I hopefully agree but I see you guys all agree. And then the vote might be either in indication that you have a potential fight which is not necessarily a bad sign. People have different opinions doesn't mean minorities but I agree that it can be a bit of a sensitive topic we have to be sensitive about it and we in the Haachi community we do a lot of work to really encourage people to try to deal with consensus naturally so we don't have to go especially into fighting but at least the benefit of the vote is that you're not stuck. The vote allows you to unstuck for the good of the project you make a decision and you go on maybe there are some people who don't like what happens but that means the project is not a problem. What if you have a vote it's 49 to 51. We have that very often in Switzerland. That's not good. We hate those. In the Haachi community I would say that it's a sign that something was not right. Either the question was bad or the topic is one that's not right. Enough work done that's not good enough.