Team Rules#

The following are the GNOME project’s rules for setting up, advertising, and closing down teams. At present these rules are informal and are followed on a voluntary basis.

Background#

Informal teams spring up all the time in GNOME, and community members are encouraged to form their own teams as necessary. Once a team establishes itself and is consistently doing work within the GNOME project, it is important that it is integrated into the rest of the project, so that other contributors can learn about the team, and join it if they want.

At the same time, teams can sometimes cease to operate, either because their members move on, or because they are no longer necessary. In these cases, it is important that the team’s online presence is updated to reflect its inactive status, so that people don’t falsely assume that the team is operating, and so that people don’t waste their time trying to join when no one else is present.

Team incubation#

All teams have to start somewhere, and GNOME’s infrastructure provides plenty of facilities for new teams to get up and running. If you are starting a new team or activity, features you can make use of include:

  • GitLab projects under personal namespaces, for file storage, issue tracking, wikis, and more.

  • Ad hoc Matrix channels on the GNOME homeserver.

  • pad.gnome.org for note taking and records.

  • meet.gnome.org for calls.

These features are a great way to start organizing a team, and we encourage community members to make use of them.

Expectations for active teams#

Active teams that are working on GNOME are expected to be visible and accessible to the rest of the project.

Active teams definition#

A team is considered to be active when it:

  • is contributing to GNOME,

  • is making use of GNOME infrastructure,

  • is active on a regular basis,

  • has been active for at least two months.

Requirements#

Once a team is considered to be active, it is expected to integrate with the rest of the GNOME project. This should include:

  • A page with information about the team. This can be a README in GitLab, a pad that is linked from team spaces, or a web page. At a minimum, team information should describe what the team does, how to contact it, and what the joining rules are.

  • A contact method for the team, which makes use of standard GNOME project infrastructure (either a Matrix channel, GitLab issue tracker, tag in Discourse, or @gnome.org email address).

  • A team space in GNOME’s GitLab instance.

    • To request this, you can file an infrastructure support ticket.

    • In some cases a team may logically belong under an existing team namespace. However, if this is not the case then the team should have top level location. As a general rule, teams should not be nested more than two levels deep (for example, /Teams/Team/Team).

  • Listing in this handbook’s teams page.

  • Optional: a global issue label for the team in GitLab (this can be requested from the Infrastructure Team).

Inactive Teams#

Teams which are no longer active can act as blockers or bumps in the road for prospective contributors. If a team is determined to have become completely inactive, it is therefore important to update its online presence to reflect its status.

Inactive team definition#

A team is determined to be inactive if there has been no observable activity in its spaces for a period of 6 months or more and at least two attempts to contact the team have not resulted in a response.

Inactive official teams#

If the inactive team forms a part of GNOME’s release process, or is charged with conducting official GNOME business, the Release Team and/or GNOME Foundation will determine which steps should be taken.

Steps may involve:

  • Recruitment and installation of new team members.

  • Assigning the team’s responsibilities to a different individual or team.

  • Updating the team’s online presence to reflect its inactive status.

Inactive unofficial teams#

If the inactive team is voluntary and does not have an official role, its online presence will be updated to reflect its inactive status. This will include:

  • Archiving any GitLab projects belonging to the team.

  • Archiving any Matrix channels belonging to the team.

  • Removing the team from any project documentation, including from this handbook’s teams page.