Report: Leadership Mini-Summit at UDS
Our UDS in Copenhagen was the busiest for me ever, but I enjoyed it a lot. There was heaps of energy, good ideas and many good conclusions for the Raring cycle. One thing I really enjoyed was the Leadership Mini-Summit.
We had it at UDSes two times before and what I feel we did better this time around was that we had more concrete examples of Ubuntu teams, their leadership and the challenges we face. It gave us a great opportunity to be together, brainstorm and learn from each other.
I volunteered to give a brief summary for all those who could not attend this time around. The following points are all based on my memory and our notes of the event. Lots of other brief conversations happened there as well.
- Actively training successors: we discussed a number of interesting experiences in teams and found that some teams had problems finding successors, especially in teams where leadership had been in the same hands for a longer time. We found that when the structures of new team, where things are more open and free-form, slowly moved towards more structure and more processes this might lead to the feeling that things are tedious to main and some fatigue.
Somebody noted that when finding new leadership and key people in the team, that it’s important to note who has a special skill (maybe presenting or organising or just a special interest), and even if they are a bit reluctant in the beginning, give them lots of positive encouragement and form a personal relationship with them. Their interests are obviously important too.
Another point mentioned was that sometimes it’s necessary and important to scale back activities if necessary. Also to harness volunteer energy when it’s there.
Some mentioned that they had been in touch with a new class of contributors: users who need more of a framework, more instructions and were generally less self-starting. Others mentioned they had met people who had misconceptions about involvement in Ubuntu, that there are requirements or they need to be “allowed to” work on something rather than just jumping in. We should definitely encourage these people to get involved. As leaders in the community we should strive to empower others to do things like give the presentations at their events rather than inviting us to do them.
It’s also important to always provide lists of opportunities (a TODO list basically).
- Milestones and mid-cycle check points for community projects.
Some team members found this very useful in watching their team projects progress during the cycle. Most technical teams use work items and blueprints which through our infrastructure are used very well. In less technical teams they are used much less.
What everybody agreed on was that they’d try to get more team reports and use work items as well.
- Ubuntu Member “incubator”.
Some noticed a concern around great contributors who for reasons of their own didn’t want to apply for Ubuntu membership. Sometimes it was lack of knowledge about it, others said they didn’t know why and other just didn’t feel they were ready yet, although they clearly were.
We will review our Membership documentation to make it clearer what Ubuntu membership is there for and how it is important.
There were also some related discussions about how some members were just interested in becoming members and then dropped their activities. Discussions around this did not come to any conclusions though.
- How to respond to “How can I get involved?”
Some teams mentioned they had had great results with one-to-one mentoring, other teams said they were overwhelmed by requests for 1-on-1 mentoring. Everybody agreed that it was important to not drown potential new contributors with “walls of text”, but that for more diverse projects a simple flow chart could help to explore interests. In there it would be important to define “requirements” for the involvement, but to be encouraging at the same time.
Some work will go into a proof-of-concept flow-chart which then could then be re-used and translated.
- Some good ideas for LoCos in general. (These ideas turned up in various discussions.)
One team had a meeting where lots of people had lots of ideas, but no concrete outcomes or plans of action. Some said that it’d help to categorise the ideas and try to group people into teams who could then collaborate and present their work the next time.
In another part of the conversation we talked about “official events” and “big events”. Everybody agreed that it’d help to generally try to also encourage small, fun events, like Ubuntu Hours for example.
Although there were conflicting views on how to organise a big LoCo in general, everybody agreed that it was important to encourage a feeling of one team, no matter which part of the state/country the contributors are from.
Many other topics were discussed as well and it was great to see how we, once we sat together, solve problems together and inspire/help each other. Thanks a lot everyone for turning up.
The work items we agreed on were:
- Daniel to write a blog post about the Leadership Mini-Summit.
- Alan to draft proof-of-concept workflow diagram to visualise activities in a team. Daniel to help publicise it and get feedback.
- José to edit the Question2Answer template and ask to get localized version of a Q&A system.
- Daniel to add flavour teams to CC checkup schedule and mail CC list about the idea to reach out to regularly teams to check in how they’re doing.
- Chris to check into automating the team reports by way of the LoCo Team Portal, and try and get it implemented. Pasi to work on a proof-of-concept for a simple website for sending and gathering team reports easily.
- Daniel to bring up the idea of creating a mailing list for the broader community (we can use it for announcements).
- Laura to mail all councils/boards who can approve members to notify the CC about new members.
- Joel to review https://wiki.ubuntu.com/Membership and send suggestion to CC.
Thanks again and good work everyone!