This UDS each track will have two session rooms, plus a breakout room. That means we will have, at least, twice as many sessions. We should some out of it with twice as many specs for new features. My question is, how will we handle twice the data?
In previous UDS’ the server track was very well documented, thanks to Adam Sommer from the documentation team. Adam was able to attend all sessions, and the documentation was uniform, because one person was responsible for the format. I think that because of Adam’s excellent work, we had some of the best documented sessions at UDS. This was good, because I am usually suffering from information overload by the end, and unable to remember my name, let alone the critical details of the discussions. We will have to come up with another solution in Barcelona. Adam will only be in some of the sessions, so the rest of us will have to pick up the slack.
If we take good uniform notes, we could come out of this UDS with more data from more discussions than ever before. This will ultimately result in a better Ubuntu. All we have to do process all the data in a usable way. So, you will probably hear me start every session with a reminder about note taking and a quick review of the format we want them in.
Free as in beer:
As usual, Server Team community members find me at UDS and I will buy you a beer.
I think the most important question that you haven’t asked is how efficient was last year’s UDS in terms of completed objectives. The number of ideas under discussion is not as important as is the ability to gather and allocate resources to complete tasks. Its perfectly fine to double the number of proposals if there is also a diubling of committed resources to see additional proposals through. But to understand that dynamic you have to start tracking task completion stats per release. You might find that you need to scale back UDS to better focus on high priority deliverables. Bigger is not always better.
It doesn’t quite work like that. Each discussion is not a promised feature, that Canonical will deliver. Sometime after UDS specs are written based on the blueprint discussions, and I will go through set their priority (to Canonical) and assign Canonical resources. Any left over blueprints, can be spec’d and worked by community members. Plus we quite often discuss things to get agreement on a direction, not to necessarily work on a feature.
You agree though that doubling the sessions will not help produce more, without doubling resources. I am very worried about our ability to adequately document all the sessions. I hope, though I am not sure, that we will end up with specs that are better defined, and simpler for the community to develop. I’ll revisit it after UDS to look at whether this was successful or not.
I suggest gobby. And I will be looking for my beer.
I think the most important question that you haven’t asked is how efficient was last year’s UDS in terms of completed objectives. The number of ideas under discussion is not as important as is the ability to gather and allocate resources to complete tasks. Its perfectly fine to double the number of proposals if there is also a diubling of committed resources to see additional proposals through. But to understand that dynamic you have to start tracking task completion stats per release. You might find that you need to scale back UDS to better focus on high priority deliverables. Bigger is not always better.