TeamVerificationGuidelines

LoCo Team Verification and Re-Verification process

Purpose

The purpose behind this page is to explain what a team needs to do in order to move from the Unverified Teams Category to the Verified Teams Category.

Team Categories

In the Ubuntu LoCo Teams there are two types of teams:

  • Unverified Teams - These are teams that have not met all the requirements to apply for Verification. They have either recently formed, or have existed for a while without an established standard team workflow, and have shown a limited amount of sustained team activity whilst working towards verification.
  • Verified Teams - A Verified team is a team that is up and running, and has demonstrated sustained team activity. They have met all of the requirements, and they have established resources up and running, and the team is working well.

Benefits of Verification

A Verified team is eligible for certain benefits such as marketing materials. A Verified team is also considered official by the Ubuntu project. The following are the current benefits:

Verificaton Process

The Process

To become an Verified LoCo, the LoCo Council needs to have confidence that the team is up and running and performing well. This requires some evidence that the team has established various resources (website, mailing list, listing of activities on the LoCo Directory etc) and is actively working on different things and working well and is more than one person. To become verified the team needs to create a wiki page (more on this below) that outlines a number of things to do with the group, and has supporting evidence.

Is Your Team Ready?

The first question to ask is if the team is ready for verification. When a New Team or its leaders determine the answer to the teams readiness is “yes”, then there are a few things about the LoCo Council’s decision making process that the team and its members should know.

Purpose and Application Criteria

The purpose of the LoCo Team verification process is to ensure that a team is an active resource for Ubuntu enthusiasts in a localized geographical area and that it offers both help and information to those who are interested in contributing to the Ubuntu Community. The LoCo Council will uses the following criteria when evaluating team applications:

  • Team naming standards followed - many resources in the Ubuntu Community depend on this naming convention, so it is of utmost importance that these naming standards be followed.

  • Team resources setup (exceptions will be made in countries that have less developed Internet infrastructures). For more details you can see the LoCo Team How To

    • IRC
    • Launchpad
    • Team Wiki Page
    • Team Mailing list
    • Team Forum on Ubuntu Forums (ubuntuforums.org)
  • Experience - what has the team done so far?
    • Has the team done any advocacy, exhibitions, support or other activities?
    • The recommendation is that the team has done at least three global activities (Global Jam Participation, Bug Jam participation, Launch parties, Release parties, etc)
    • Six to Eight months of activity prior to applying and detailed team reports (atleast one per cycle) are also recommended. However, it is important to understand, that depending on activity levels a team may be better advised to wait to apply.
  • Roadmap - Does the team you have an idea of what goals it wants to achieve and which projects it should work on to achieve those goals?

  • Future planned activities - Teams which have future events planned gives the LoCo Council confidence that a team is committed to staying active and building their team. These future planned activities should be laid out and included in the roadmap, and added to the LTP (LoCo Team Portal) if at all possible.

  • Membership - Are there Ubuntu members on the team? Having an Ubuntu Member in a LoCo is not required; but however, Team Members with Ubuntu Membership shows wider Ubuntu involvement of not only the Ubuntu Member(s) but of the scope and knowledge of the team as a whole.

Note: The LoCo Council will factor in all of the above criteria to make a decision on the applying team’s verification status. There is no magic formula of time or quantity of activities that will guarantee a team verification. The real concern for the LoCo Council is that a team will stay active.

  • Has the applying team demonstrated the ability to meet future goals and have these goals been successfully communicated to the LoCo Council?

  • Has the applying team demonstrated continually growing its member base as to ensure that team leaders and highly active participants aren't setting themselves up for burnout or withdrawal from the community, thus creating an inactive team in a short time after verification?

  • Has the applying team indicated to the LoCo Council its understanding about what it means to be an Ubuntu LoCo Team and demonstrates how its mission differs from that of a LUG

How to Write an Verification or Re-Verification Application

The success of a team’s application to become a Verified Ubuntu LoCo team largely rests in ts application wiki page. The application wiki page should use the following naming protocol:

  • <LoCoTeamName>VerificationApplication2012

    • ex: UKTeam/VerificationApplication2012

The Verification process will be followed in a private bug in Launchpad. Please, do not change the bug status as the LoCo Council will change it accordingly to follow the Bug Status Guidelines.

NOTE: An example application is available at LoCoExampleApplication. This shows an applying team the kind of structure that the page should form.

Application Tips

Here are some important tips

  • Do not change the structure of that page - use the same section headings and structure of the LoCoExampleApplication page - this makes it easier for the LoCo Council to read the page it considers the team’s application.

  • Use as many links and references as possible - this is essential! In the Roadmap and Experience sections and elsewhere on the Verification Application Wiki, you should provide web links to websites, blogs, team reports, mailing list archives etc. that confirm the points you make on the application. So, Here is an example: A team lists an activity in the Experience section of the its Verification Application wiki, then it should link to a report about the activity in a blog, flickr, wiki page or other resource. Pictures always help!

  • Be concise, detailed and clear - while we the LoCo Council do not want to see thousands of words, we do want to be able to gain a full understanding of the teams past experience, current activities, and future goals, as well as how those will be achieved.

Re-Verification

Note: Verified teams will be re-assessed every two years to maintain their verified status as a part of health check on the team and a check in. Bug Reports will be opened for teams requiring re-verification.

If a team is applying for reverification you the wiki page should use the following naming protocol:

  • <LoCoTeamName>ReVerificationApplicationYEAR

    • ex: UKTeam/ReVerificationApplication2012

The re-verification application is similar to the verification application detailed above. The re-verification application wiki page should summarize the LoCo Team’s accomplishments of the past two years and outline plans for the future.

Each cycle, LoCo contacts from LoCo Teams with approaching review dates will be contacted privately and asked to submit applications. If those LoCo Teams are prepared for re-verification, the team’s contact will add the application to the LoCoCouncilAgenda and or Bug Report or the LoCoCouncil Mailing List. The LoCo Council will vote on the team’s re-verification application. The vote can be done via the Bug Report or at a LoCo Council Meeting or Mailing List. This flexibility is allowed to account for variations in timezones.