From Ingres Community Wiki

Contents 1 Overview 2 Background 3 Notes 4 Documentation 5 Code Sprint Checklist 6 Development project 7 Abandoning a project 8 Dispute resolution process 9 Mentor responsibilities 10 Display status of project 11 Sample Project Classifications 12 References

Overview

This page documents a checklist and provides sample templates to help community members setup and run a code sprint. It includes some suggested procedures to follow, lists the type of information you might want to communicate to the community and also provides links to useful documents which will help everyone involved. Also we have provided some pointers about running a community development project and combining with a user group meeting often run at the same venue.

Background

This document was created during a meeting Tues 29 Sep 2009. Joe Kronk, Kim Ginnerup, Paul White attended. Aim of the meeting was:

• Create a structure around OpenROAD Code Sprints and ongoing community development projects
• Simplify organising Code Sprints
• Coordinate contributions from volunteers and commercial entities
• Streamline community development process
• Document a process to move functionality easily towards the finished product.
• Provide guidance to all members of project teams.

During the meeting we recognised this page could be used by all Ingres community development projects and we therefore attempt to make the wording more generic. Primarily the discussion revolved around getting OpenROAD internal 4GL and 3GL enhancements into "e1daily" from which point it can be easily integrated into the Enterprise OpenROAD version.

Notes

The following section holds miscellaneous notes which havent been fully expanded.

Lightweight vs heavyweight projects. Defining.

Visibility to the community, Communication

• OpenRoad Users List
• Community forums
• Community wiki
• Wish to avoid spam

Protect restricted or proprietary source code which is not allowed to be disseminated to Public.

Security. Non disclosure agreements.

Procedures for setting up development environment including tools and 3rd party software and licenses.

Functional Specs contents to include:
test plan, documentation, programming standards, upgrade requirements, backwards functionality

Classifying a Project:
4gl, 3gl, User Interface, performance, productivity, workflow, stability, utilities, workbench, language enhancements

Documentation

List of documents to be created and maintained:

• Formatting / document / programming styles
• Project Life cycle
• Procedures
• Test Plan and Test Case
• Specification template
• Integration Plan template
• Naming standards
• Version Control

Code Sprint Checklist

Checklist for setting up a code sprint.

Plan ahead

• Choose venue
• Identify accommodation, transport, meals
• Identify secretary / contacts
• Budget, Sponsors, out of pocket expenses
• Approval from Ingres - Of course we'd like their assistance
• Setup wiki
• Technical requirements
• Invitations to forums and mail lists
• Collecting responses, contacts.
• Participation - getting ideas
• Voting for code sprint projects
• Agenda
• Confirming attendance
• Plenty of treats
• Cleanup
• Coordinate transport

Development project

Checklist to follow to get the project into the main codeline.

• Idea, project brief, justification, classification
• Open issue, enhancement request, email, SIR
• Minimum requirements
• Subforum creation for the project, Mentor assigned.
• Functional spec, prototype (optional), Design review, proof of concept (optional),
• Scheduling completion, cut off for release to QA, GA release.
• Implementation, doing the work, coding, testing, docs, etc.
• Write integration plan, code diffs, code review
• Final approval of Integration Plan
• Submit code to main codeline
• Release cycle, QA by Ingres Corp

Abandoning a project

The team may decide to stop working on a project for a number of reasons. Examples: Deferred due to lack of resources, or conflict with another project, change in requirements, belongs in a different product area, waiting for another project to complete, or just plain lack of interest. If a project is going to be abandoned, we would prefer to identify the situation as early as possible so we can avoid wasting everyone's time and money. This section will make suggestions on how to clean up after an abandoned project and, if possible archive the information for future use if required.

Dispute resolution process

If open discussion on the forum cannot resolve a disagreement about some piece of technical functionality or coding style or documentation wording, the discussion can be put to a vote. The mentor will act as moderator in these activities.

If development team members are not able to get along we will escort them out back and conduct a hanging followed by draw and quartering exercise.

Mentor responsibilities

This is the only "assigned" position for the life of a development project. The project mentor does not have to be a subject expert but should be comfortable with the tools and technology and be able to locate information or call on extra resources for the development team.

Display status of project

* Simple visual or graphical summary to indicate where a project is at. 

• Use a Progress gauge or status indicator.
• Help community members can easily see where they can contribute.
• Report, dashboard overview of all projects to indicate activity.
• This could potentially be delivered via an OpenROAD appserver at Ingres corp or at a customer site.

Sample Project Classifications

Used to help classify and search for projects. A project should fall into several of these classifications

• Language Enhancements
• 4GL - Change needs to be done in 4gl code
• 3GL - Change needs to be made in 3gl code
• Performance - Improved speed for
• User Interface - Visibile enhancements
• Productivity - improvements in workflow, additional features to aid debugging
• Stability - bugfix, support for new operating systems
• Utilities - tools, editors, external components.

example classifications:

• 4GL Editor project: 4GL, 3GL, User Interface, Productivity, Utilities
• Trace Window timestamp: 3GL, Productivity
• Context Sensitive Help: 4GL, Productivity
• Procexec new attributes: 3GL, Language, Productivity

References

Painless Functional Specifications - Joel Spolsky
Part 1: Why Bother?
Part 2: What's a Spec?