Approval and Re Approval Process

Approval and Re Approval Process

I’ve had some time recently to review a lot of wiki applications for LoCos.  It is truly amazing the amount of work some teams do and is a great source of ideas to try for other teams.

With that said, I’ve also seen some wiki pages which are less than clear on what the team is doing which makes it very hard to judge. So I thought I’d put down some best practices to make it clearer what is expected.

So firstly let’s recap:

The LoCo Council has been tasked with identifying Approved LoCo teams which were approved over 2 years ago and thus are due for re-approval. The criteria for re approval is the same as for approval which is outlined on the getting approved instructions and the LoCo Council guidelines can be found at the team approval guidelines.

It should be noted that from the day your LoCo is approved, you should continue to document all events and history of your LoCo for this re approval process to make it clear and visible to all.

Now it is safe to say some teams do not continue documenting their work so when it comes to re approval time it’s panic stations, all hands on deck!  Things you can do to help elevate this are the following

  • Use the LoCo Directory to log all of your events it will make it easier to write up about them and possibly in the future link to past events
  • MONTHLY Reports folks, only a handful of teams use them and there are more teams there that SHOULD be writing monthly reports, list your IRC meeting, any real life meet up, projects people are working on in relation to Ubuntu.
  • Take photos of your events it’ll help in the long run, assign someone at each event to take photos and even create a gallery in one place to link to them

When it comes to the creation of the Application be it for Approval or ReApproval it’s the same thing just NAMED DIFFERENTLY.  You just need to document it. LOTS OF DETAILS PLEASE! We’d rather have too much then not enough details as the meeting is short and we have a lot of teams to get through.

What is expected of a LoCo Team

  • All teams must provide the Council with a wiki page (in English preferably) with details outlined in
  • The team should have demonstrated a significant and sustained contribution to the Ubuntu community, from participating in a ubuntu-related project, documentation, localization, development (bug reports and packaging, marketing, participating in FOSS events, release parties. All of these abiding the Code of Conduct and following the LoCo team project’s policies.
  • The team should have public wiki pages and an open public mailing list set up, these initial resources indicate open participation and they provide the Council with a log of the Team’s activity.
  • The team should have an entry in
  • The team should have been running for at least 4 months and have had a consistent set of interactions with each other (council members should look at mailing list activity to assess how much activity there is) – you should also assess IRC activity where applicable.
  • The team should have a good roadmap and a good set of goals that they want to achieve, The Approved status is only a confirmation of their effort and it is also a commitment for further community activity.
  • Leadership within the team must be build upon fairness and openess. The team must be in agreement with the fair apointment of a leader. This leader must represent the team in different situations in an efficient and effective manner, so the leader’s commitment towards the team is paramount.
  • Has there been much conflict in the team, and if so, has it been resolved?: This is a very important sign of a team that is mature enough to face further situations in the future. Resolving issues is definetely a learning experience for LoCo Teams.
  • Do the council feel this team could be trusted with additional resources such as additional CDs and being sent equipment for use?, Extra resources encourage more participation therefore, Being able to administer their resources is paramount, making sure that the team has what they need to promote ubuntu locally .
  • Is this team setting a good example to the community? The Team must serve as role for new teams. The teams participation in LoCo team communication channels (Mailing list and IRC) is also encouraged, this way the team can be sure of that the great work done by this team gets shared with the whole LoCo Team community.

We also know that from time to time things don’t run smoothly, but how you cope  resolve and work things out is what we would like to know about.  It’s not a bad thing unless you hide it.  On the wiki page tell us how many is in your TEAM, IRC Channel, Mailing list, Forums and link to them.  We need the details, please don’t expect us to go looking for them, your team is one of a number of teams being reviewed.

When it comes to the IRC meeting if you are called for one, don’t come alone.  You are not in the team alone.  You don’t run the team alone.  BRING PEOPLE  TO CHEER THEIR TEAM ALONG!  It’s a team effort remember this when doing the application ASK FOR HELP, ASK  FOR CONTENT, you may miss something when someone else has blogged or taken photos of something.

Remember the LoCo Council idles in #ubuntu-locoteams if you want us to look over your application to give you some pointers just ask.  Remember being called for reapproval is a normal procedure and do not panic :)

Finally some really good applications just to give you an idea of what we’re looking for are the following

  1. Colombian LoCo
  2. Italian LoCo
  3. French LoCo

2 Responses »

  1. I’ve been following the re-approval happenings with interest, so I have an idea of what to expect when the LoCo I’m in comes up for re-approval. So far, it looks like the process mirrors initial LoCo approval and Ubuntu Membership meetings in that the keys are 1) documentation, 2) documentation, and 3) documentation :)

    As you mentioned, team reports are a really good way of keeping track of things. I’m also thinking that an ongoing “portfolio” of events (updated after each event) would be a good idea, so that when re-approval comes around, everything is done already, and there’s no scrambling at the last minute.

    One thing I’ve been wondering: for re-approvals, does the council want applications to focus on just things that happened since the last (re-)approval, or should they contain information on everything since the LoCo started?

  2. Hi,
    I wrote the French Approval Application page (i don’t put a “re” in front of that because it is like an approval application like Laura said). Because I’m not smart, i asked to our LoCoCouncil contact paultag what they expect to find in this page after writing a first draft. They love photos, photos with lot of people on them. The charts are good too, they can see in one view the importance of what you want to show.

    I can’t help for the photos, but i can help for the charts.

    First the irc channels charts, one of our team member point me to this site it’s excellent to show the amount of users frequenting your channels. For example for the #ubuntu-locoteams channel.

    Second the mailing lists charts, I choose to show the number of posts per months, it’s easy to count. You only have to go to the list archive, and for each month you have the number of posts. You can also use the size of the gz files they are an indicator also of the activity.

    Finally the websites charts. I can’t help for that, you have to use tools, or to make your own tools to count on data-files or databases significant informations like number of new users, number of posts, … don’t take too much time on that if you can’t do that easily.

    Oh, and another important thing, you are a team, don’t do that alone, i had help to find the informations, to review the page, to correct my bad english, … In prevision of that application we made a meeting in June asking for reports on each part of our activities.

    Have fun

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>