Process

Differences between revisions 4 and 5
Revision 4 as of 2010-06-01 19:46:53
Size: 6519
Editor: c-24-23-242-54
Comment:
Revision 5 as of 2010-06-01 20:16:21
Size: 6492
Editor: c-24-23-242-54
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 25: Line 27:
Each stage is broken down in a series of components, as illustrated below:
Line 26: Line 30:

I will now outline each of these different stages.
Line 29: Line 35:
The first step is to get the package ready for assessment. ''This step prepares the application ready for assessment by the Application Review Board''.
Line 31: Line 37:
 * Package the application.
  * Using standard Debian packaging system.
  * Preferably new development uses Quickly, and the simplified packaging facilities there.
 * Upload to a PPA
This step has two components:

 * '''Package the application''' - package the application ready to be installed and run.
  * The application should be packaged using the standard Debian packaging system. Documentation for this process is in the Packaging Guide (https://wiki.ubuntu.com/PackagingGuide).
 * '''Upload to a PPA''' - the package is uploaded to the user's PPA
Line 36: Line 43:
  * In the future we may want to have a button in the PPA view in Launchpad to trigger the application assessment process.

Resource Requirements:

 * No strict requirements for 10.10.
 * Optional: button to trigger the assessment process.
Line 45: Line 46:
The second step is for the developer to formulate a submission. This step gathers a set of data that is presented to the assessment board: ''The second step is for the developer to formulate a submission to present the application, supplying additional information about the application to the Application Review Board''.
Line 54: Line 55:
 * Notes (text with information pertinant to the assessment)  * Notes (text with information pertinent to the assessment)
Line 57: Line 58:
Submission process. We have two submission processes, one is cheap and one is expensive. To file an application, the following process is executed.
Line 59: Line 60:
Cheap:

 * Using a pre-defined template, user fills out a wiki page with the above data. This wiki page is added to a list of pending submissions on a master wiki page.
 * User emails a standard email address (mailing list) with the application link.

Cheap Requirements:

 * Wiki template
 * Mailing list for assessment submissions to be sent to.

Expensive:

 * User goes to a web address to submit their application (http://submitmyapp.ubuntu.com).
 * User signs in with the Ubuntu Single Sign On (this means we can gather some of the submission data automatically).
 * The form has a series of entry points for the submission data above.
 * The website generates a wiki page and automatically sends an email to the submissions mailing list.

Expensive Requirements:

 * Available ubuntu.com sub-domain.
 * Web form application to coordinate the process.
 * Mailing list for assessment submissions to be sent to.
 1. User uses the pre-defined template (outlined below) and provides all required content.
 1. This filled-out template is emailed to `app-reviews AT ubuntu DOT com`.
 1. The application review appears in the email moderation queue for the Application Review Board.
Line 106: Line 88:
= Supplementary Documents =

== Application Submission Template ==

{{{

About You:

  NAME:
  EMAIL ADDRESS:

The Application:

  APPLICATION NAME:
  LICENSE:
  PPA URL:
  SUPPORT RESOURCE (URL to forum / mailing list etc)

Please add additional notes about this application review below:


}}}

== Application Review Board Codification ==

Post Release Application Submission Process

THIS DOCUMENT IS IN DEVELOPMENT BY jono AT ubuntu DOT com - THIS IS NOT FINAL.

The purpose of this document is to outline the process where by applications can be submitted to a community-driven evaluation board for review

Goal Definition

Problem

The current Ubuntu process for getting an application into an Ubuntu archive is slow and complex and unapproachable for application authors. This complexity of process is preventing application authors from making their software available in Ubuntu.

Solution

The high-level solution is to provide a facility in which application authors can propose their application for inclusion in the Ubuntu Software Center. This inclusion can happen at any time (including post-release).

Process

The process for submitting an application has three primary stages:

  1. Preparation - get your application packaged and available for assessment.
  2. Submission - submit the package to be reviewed for inclusion in the software center.
  3. Assessment - the assessment process in which our Application Review Board decided whether the application is admitted to the software center.

Each stage is broken down in a series of components, as illustrated below:

Process

I will now outline each of these different stages.

1. Preparation

This step prepares the application ready for assessment by the Application Review Board.

This step has two components:

  • Package the application - package the application ready to be installed and run.

  • Upload to a PPA - the package is uploaded to the user's PPA

    • The package is reviewed from the PPA.

2. Submission

The second step is for the developer to formulate a submission to present the application, supplying additional information about the application to the Application Review Board.

The data to be gathered in this process is:

  • Name (text)
  • Email (text)
  • Package to be assessed (URL to PPA)
  • License (text)
  • Support contact (URL to forum / mailing list etc)
  • Notes (text with information pertinent to the assessment)
  • Optional: Bug tracker (URL)

To file an application, the following process is executed.

  1. User uses the pre-defined template (outlined below) and provides all required content.
  2. This filled-out template is emailed to app-reviews AT ubuntu DOT com.

  3. The application review appears in the email moderation queue for the Application Review Board.

3. Assessment

The third step is the assessment process. This step requires an Application Review Board (ARB). I recommend that this board has the following attributes:

  • 5 people
  • Appointed by the CC/TB
  • 1 year term
  • Everyone welcome to nominate themselves for positions.
  • Report to the CC.

The ARB recieves notifications of applications for review via the mailing list and reviews the wiki page that is available from the submission step above. The process in which it is reviewed is:

  • The assessment process is performed over email to reduce bottle-necks surrounding real-time IRC meetings.
  • We should commit to an SLA regarding the outcome of the review. My recommendation would be two weeks.
  • The review happens by the ARB reviewing the application wiki page and voting on their support of the application.
  • The outcome of the vote is:
    • Three or more +1 votes - the application is approved.
    • If there are more than one -1 votes - the application is discussed in more detail and possibly deferred.
    • Three or more -1 votes - the application is rejected.

Requirements:

  • Documented guidelines about how the assessment process works.

Supplementary Documents

Application Submission Template

About You:

  NAME: 
  EMAIL ADDRESS: 

The Application:

  APPLICATION NAME:
  LICENSE:
  PPA URL:
  SUPPORT RESOURCE (URL to forum / mailing list etc)

Please add additional notes about this application review below:

Application Review Board Codification

Discussion

If this idea is successful, I would think there could be a LOT of submissions. Perhaps some sort of filter mechanism (community voting or automatic sorting by some "quality" metric or some such?) could help the ARB in prioritizing if this turns out to happen.

Some thought should be given to security issues, e.g. if someone uploads an app which contains a trojan or something.

The last thing we need is another board IMO, can we do a separate instance of brainstorm and allow Ubuntu members and developers to vote on submissions. It would be a lot more scalable than having a board to handle everything. --fagan

I think it makes sense to have a board to handle conflict resolution, or to override decisions made against community guidelines (basically, as an arbiter of last resort). However, in line with the rest of Ubuntu, we should have a process that is more community based. I would recommend a submission process that allows an X week voting period, with the ability to circumvent that process by appealing to the ARB. We would also allow user reviews of the product, and enough negative rankings (perhaps categorized into quality, security, usefulness, etc rankings) would take an app out of the repository until the problem is addressed. --ilya haykinson

1. I believe you can improve a bit on submission process. A button implemented in PPA (or project page) can bring all the information required for submission, such as names, emails, project/product description, etc. It will get into maillist automatically. And you may get this without subdomain.

2. I think it should be a community process. If ARB would have to decide for each application, then in time due to the sheer number of the submitted applications

  • a) ARB would only have time to work on approving/reviewing applications, and nothing else b) It will take forever for the application to be reviewed/approved

The community can definitely make this process easier. -- Alex Lourie

PostReleaseApps/Process (last edited 2011-02-15 17:50:53 by allison)