Project review

Launchpad Registry admins can review projects. Projects are reviewed to ensure:

• Proprietary projects have commercial subscriptions
• Spammers are not using Launchpad
• The project name space is not cluttered with fake projects
• Communities are sharing projects

The licensing issue is most important. The latter items are indicative of communication and usability issues. Spam is a big concern, but the Launchpad community could possibly help with that.

Launchpad gets between 10 and 30 projects registered every day. Saturdays and Sundays have few while Mondays and Tuesdays have many.

Daily review of projects that need review

View review projects to see a listing of the projects that need review. This queue should be driven to zero. It takes between 5 and 15 minutes to do so, and it is much faster to review each project in a separate tab. View the project title, summary and description to judge if the project is legitimate, is a test, is a mistake, or is spam. Use the Review project link to mark the project reviewed; about 80% of the time you will approve it.

Do not do judge value or viability of the project! A review of projects revealed that half the projects that we inquired about were thriving, and half of the projects we did not inquire about had failed. Let time be the judge of value and viability.

1. First search for special case licenses that may need correspondence. There are the "I don't know" and "Other" licenses:

• I don't know yet: If the project does not look like spam or a test, mark it reviewed. Do not approve it because the project could later add proprietary content.
• Other/Proprietary: If the project does not look like spam or a test, mark it reviewed. You cannot approve it.
• Other/Open Source: This is hard for those not familiar with the

  definition of Open Source. Launchpad is happy to host any compliant project for free. Many users chooses licenses that are approved, search for Other/Open Source examples. Many users choose Other/Open Source, then list a proprietary licenses, such as CC-NC. When in doubt, talk to Curtis or William.

2. Second view all projects that need review (uncheck the three licenses).

• Review all the projects owned by the Registry Admins first. As a member of the team, you own this project. Half of the projects are created by users registering a project for a package, the other half are when users abandon a new project (testers?). Mark the projects that have code, or link to Ubuntu as reviewed and approved. Deactivate projects that have no assets that a community can use (and mark it reviewed).
• You may want to scan the list of projects for "test" or "prueba". See the Actions section below about how to deal with them
• The remaining list of projects will claim to be legitimate free software. Opening several in tabs is the fastest way to check the title, summary, and description to verify the project is not spam or an accident (the user wanted a team, archive, personal repository). Choose the Review link to mark the project as reviewed and approved if all is well. Otherwise see the Actions section below to handle issues.
• Note OpenERP is a very active project and it has dozens of localisation projects. They are legitimate. they sometimes state that they are doing translations, but that is really the case.

Weekly review of projects with issues

Unapproved and proprietary projects need follow up. (The scripts mentioned herein can be found in lp:lp-dev-utils.)

• View reviewed proprietary projects. Registry admins need to deactivate proprietary projects older than two weeks old and have never had a commercial subscription. They are at the bottom of the last page of the listing.
  Run ./disable-license-proprietary-notice.py <project-id> to send an email and deactivate the project.

• View reviewed and unapproved other open source projects. Locate the projects that are older than two weeks that have license conflict issues
  Run ./disable-license-conflict-notice.py <project-id> to send an email and deactivate the project.

• Search for all reviewed but unapproved projects for all licenses except for Don't Know and OTHER (scary search). The Other proprietary will still appear in this listing. Ignore those with commercial subscriptions. Projects at the bottom of the list were probably not approved because there is something proprietary about the project. Maybe it was not clear if the project was appropriate. See the action section below for how disable the project based on its circumstances.

Commercial Admin responsibilities for Other/Proprietary license projects:

• Commercial admins extend all Canonical commercial subscriptions to beyond

  2020 to separate them from customers.
  Run ./extend_subscription.py --force -d <enough days to reach 2020> <project-id>

• Commercial admins search for projects that have expired commercial

  subscriptions
  Run ./disable-license-proprietary-notice.py <project-id> to send an email and deactivate the project.

• Commercial admins search for projects that will expired in the next two weeks and send an email asking the projects to renew their commercial subscription.

Actions to address common issues

• The project is spam
  Deactivate the project. Locate the user and suspend him (and note why the user is suspended).

• The user wanted a team, archive, repo
  Run ./disable_project.py <project-id> to send an email to the maintainer and mark the project are reviewed and inactive.

• The project is a test
  Run ./disable_project.py <project-id> to send an email to the maintainer and mark the project are reviewed and inactive.

• The project is a translation of a project already registered
  Run ./disable_project.py --msg=2 <project-id> to send an email to the maintainer and mark the project reviewed and inactive.

• The project is a duplicate of an existing mirrored project
  Run ./disable_project.py <project-id> to send an email to the maintainer and mark the project are reviewed and inactive.

• The project claims to be open source, but discriminates against a use or group
  Run ./license-conflict-notice.py <project-id> to send an email and mark the project as reviewed.

• The project claims to be open source, but does not link to a license or describe a license
  Run ./license-ambiguous-notice.py <project-id> to send an email and mark the project as reviewed.

• The project license/assents are in conflict, they are not free and

  the project maintainer has not fixed the issue after two weeks.
  Run ./disable-license-conflict-notice.py <project-id> to send an email and deactivate the project.

• The project is proprietary, but the maintainer has not purchased a

  commercial subscription after two week
  Run ./disable-license-proprietary-notice.py <project-id> to send an email and deactivate the project.

Open bugs

There are many things that can be done to improve the review experience. The queue could be reduced by improving registration so users do not make mistakes. The emails could be sent automatically or included in actions. For example, the automatic sending of the Lp license policy to "I Don't Know" projects encourages more than half of them to get a lice in 48 hours.

See the listing of related chr project bugs