OpportunisticDeveloperWorkflow

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:

Main Image

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

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:

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:

Upload Fix

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

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

Ground Control Workflows

Comments

Comments can go here.

OpportunisticDeveloperWorkflow (last edited 2010-10-23 15:32:39 by mail)