= Opportunistic Developer Workflow =

'''PROJECT AWESOME OPPORTUNITY'''

'''This document is a work in progress for how we can integrate opportunistic development workflow into Ubuntu. Please leave comments in the Comments section below.'''

== Overview ==

In recent months we have seen the development of multiple components that make opportunistic development easier for our community to get involved in. This includes:

 * Quickly
 * Ground Control (GC)
 * Acire / Python Snippets

This document outlines some integration opportunities for Lucid in building this functionality into the desktop. This will not be shipped with Lucid by default, but we expect to have a single package that enables this functionality in universe.

The goal is to support three primary operations for opportunistic developers

 * '''Create an application''' - for a user who wants to create a new application, this should be as simple as going to your ''Projects'' bookmark in Nautilus and clicking a button to create a new project. Quickly will create this project for you using it's Python framework in our first release of this project.
 * '''Download a project and collaborate''' - this is where the user can download a project from Launchpad, contribute code and submit a merge proposal. This is currently supported by Ground Control.
 * '''Fix a Bug''' - this is a key feature that could have significant impact on our bug workflow. This optimises the process of how a user can identify a bug to fix and ease steps involved in grabbing the code and contributing the fix back to the project.

=== Create a Project ===

Workflow:

 * GC (Ground Control): Show 'Create Project' button.
 * Quickly: Show new project dialog box (this is a new feature in Quickly), take project details and generate project.
 * Skip to 'editing' section below.

=== Download a Project ===

Workflow:

 * GC: Show dialog to search for a project in Launchpad.
 * GC: Download code to the Projects directory.

=== Editing Code ===

User clicks on project directory to see source.

 * GC: Detect if a quickly app.
 * If it is quickly app:
  * GC: Ask quickly what buttons to present. Quickly can expose what features can be mapped to buttons to be displayed in Nautilus.
 * If not quickly app:
  * GC: Show edit code button.


=== Committing Code ===

Code has been edited. Now potential for a commit.

{{{
If a Quickly app, buttons already mapped to quickly actions.
}}}

If not a quickly app:

 * GC: Show 'commit code' button.
 * GC: User clicks button, show commit dialog.
 * GC: commit code and push.

=== Submitting a Merge Proposal ===

Code is now committed and pushed.

 * GC: Show a 'submit merge proposal' button.
 * GC: User clicks it, show dialog box and create merge proposal.

=== Fix a Bug ===

 * GC: Show 'Fix a bug' button'.
 * GC: Show dialog to enter a bug report.
 * GC: Download branch to Projects dir.
 * Now follow the 'edit' section.
 * GC: Show a 'Upload a fix' button.
 * Now follow the 'commit' section above.
 * GC: Attach pushed branch to a bug report.

==== Visual UI outline of the fixing a bug process ====

This is how the bug fixing workflow will work. We start with the normal Ground Control view with the three options:

{{attachment:front.jpg|Main Image}}

When the user clicks the ''Fix Bug'' button the following dialog box appears

{{attachment:enterbug.jpg|Enter a bug number}}

For the first cut of the feature a bug number is required, but the feature could also be triggered in the following ways:

 * There is an option on the Launchpad project page saying ''Fix a bug on your desktop'' (or some other descriptive term) and when you click that link, Nautilus opens up and is fed the bug number.

When a bug number is submitted, Ground Control will check the branch that the bug affects (typically trunk) into your `Projects/` directory. You can then go and hack the code:

{{attachment:hackfix.jpg|Hacking on a fix}}

When a source file in the branch is changed (and ultimately the coder fixes the bug), we now see an ''Upload Fix'' button:

{{attachment:uploadfix.jpg|Upload Fix}}

At this point the branch has the fix committed, so the coder clicks the button and then sees this dialog box:

{{attachment:uploadfix-dialog.jpg|Upload Fix Dialog}}

This dialog box asks for the following:

 * The first box is the content that goes into the commit message.
 * The second box is the content that goes into the merge proposal.
 * The third box is optional additional characters for the branch name.

When the user clicks the OK button, the following process occurs:

 * Bazaar commits to the local branch.
 * The branch is pushed to the branch location specified.
 * The branch is added to the bug report.
 * A merge proposal is made.

=== Workflows as Flowchart ===

{{attachment:workflow-1.png|Ground Control Workflows}}

== Comments ==

Comments can go here.