Skip to content

start:

Glow Open Software Process - Check-lists

Index
Glow Project
Coding Guidelines
UI Guidelines
Accessibility
Milestone Checklist
Microstone checklist
Smoke test
Commit checklist

Index
Index This page
Glow Project Project-wide process guidelines
Coding Guidelines Rules affecting each source file
UI Guidelines Rules affecting appearance and behaviour of the user interface
Accessibility More UI rules for keyboard navigation and accessibility
Milestone Checklist Checklist before releasing a milestone of Glow (stable updates for users)
Microstone checklist Checklist before releasing a microstone of Glow (inter-milestone releases, primarily intended for contributors (developers, testers))
Smoke test Minimal test to ensure that a code commit does not break Glow
Commit checklist Checklist before commiting code to Glow


Glow Dev mailing list dev@groupware.openoffice.org


Glow Contributors site http://groupware.openoffice.org/glow/dev/


Note: The web-page is created from the Calc spreadsheet checklists.sxc; the script ../www-tools/clean-calc-html.sh tidies the html output slightly for publishing

Glow Project
Id# Category Description
1 Develop Write a short SPEC mail (subject “SPEC: “) to the Glow Dev mailing list before starting to implement a feature (wait 2 days for response, proceed if approved)
2 Develop Extend automated tests and update manual tests at the same time as committing a code change that adds a feature or breaks a test
3 CVS Only core team may commit a code change; the smoke test (manual and automated tests) must work successfully
4 CVS Add a brief entry to the glow/docs/release-notes/glow-<milestone>.txt file after making a change to the UI, a public API, a file-format or any other public interface
5 Release A new public minor release (milestone) will be made every 10-12 weeks; see Milestone checklist
6 Release A new public micro-release (microstone) will be made every 2 weeks; See Microstone checklist

Coding Guidelines
Id# Category Description
1 Comments Every source file must have the OpenOffice.org header comment (copied from another Glow source file)
2 Comments Every source file should have an introductory javadoc comment before the class/interface name; this should state the purpose of the class and any suggestions for correct usage
3 Comments If a code change is planned for later, use a comment with the “@todo” keyword to highlight this
4 Comments All public members should have at least a 1-line javadoc comment
5 Comments All methods that have two or more parameters that have the same type should have a javadoc comment for each parameter
6 Clarity All public string and numeric constants should be declared static final at the top of the class file
7 Portability All code should be written portably; the java.io.File.pathSeparator* should be used (especially when displaying file names and paths)
8 I18n All code should use the appropriate classes from java i18n (see http://java.sun.com/docs/books/tutorial/i18n/intro/checklist.html and http://java.sun.com/j2se/1.4.2/docs/guide/intl/intlTOC.doc.html)
9 Style Use 4 spaces for indent, no tabs; use UNIX line-end convention
10 Style Refer to Java coding guidelines (http://java.sun.com/docs/codeconv/) especially for naming, commenting and structure; above guidelines override those in ection 3.1.1 (Beginning Comments)

UI Guidelines
Id# Category Description
1 Accessibility Follow the Accessibility rules (see separate page)
2 Font Use Glow default font (GlowUISettings.getFont()) where possible
3 Font Alternative font sizes are defined in glow.ui.GlowUISettings; any alternate font should be derived from these fonts
4 Font Only use PLAIN and BOLD font style
5 Spacing Use DIALOG layout constants defined in glow.ui.GlowUIConstants
6 CTL Use only LEADING and TRAILING ComponentOrientation (to also support right-to-left locales)
7 CTL Use default orientation for LayoutManager
8 Layout Dialogs should align related components into logical groups (rows or columns)
9 Labels Dialog labels should have a trailing ':' character
10 Labels Labels should be capitalized properly (e.g. “Name:”, “Alternative Name:”, “Name of Attendee:”)
11 Quality A UI may be temporarily incomplete, but only working features should be visible in the Glow UI (no buttons that do nothing, text edits that don't change anything, empty tabs on tabbed dialogs);

Accessibility
Id# Category Description
1 Navigation Always set the focus when creating or re-displaying a dialog
2 Navigation The tab order (when Tab key is pressed) should correspond to the logical layout of the components
3 Navigation Every text-button and menu should have a unique mnemonic
4 Navigation Every label has a mnemonic to set focus to the related component (e.g. JTextField or JList) using setMnemonic(); use setLabelFor() to identify the related component
5 Navigation Every important menu item has an accelerator set using setAccelerator()
6 Identification Graphical toolbar buttons and static graphics (including icons in trees and lists) should use an ImageIcon that has a description
7 Identification Every toolbar button, checkbox and radio button should have a tooltip (setToolTipText())
8 Identification Every component that has no label should have a user-readable name set using setAccessibleName()












References:
http://www-3.ibm.com/able/guidelines/java/accessjava.html


http://java.sun.com/docs/books/tutorial/uiswing/misc/access.html

Milestone Checklist
Id# Category Description
1 Prepare The Glow *minor* version number is updated (x.Y.z) for the build
2 Microstone All microstone guidelines also apply to a milestone
3 Quality Glow quality team carry out feature tests for all features that have been changed
4 Quality Glow quality team leader mails dev@groupware.openoffice.org (subject “QA: <result OK or Failed>”)
5 Package Refresh the Web Start download is refreshed; test and verify build number (in Glow “about” dialog)
6 Announce Active project leader sends an announce mail to announce@openoffice.org and announce@groupware.openoffice.org

Microstone checklist
Id# Category Description
1 Prepare Update the Glow *micro* version number (x.y.Z) for the build
2 Package The binaries are built in a clean new CVS workspace (created using 'cvs co')
3 Package The release notes are updated for the micro version number; any new minor bugs or upgrade requirements are identified
4 Quality 100% of unit-tests pass
5 Quality The smoke test passes 100%
6 Quality If a unit-test or smoke-test is broken, mail Glow developer mailing list with subject “BROKEN: ”
7 Package Refresh the microstone binary download
8 Announce Active project leader sends an announce mail to dev@groupware.openoffice.org and users@groupware.openoffice.org

Smoke test
Id# Category Description
1 Run Glow must start correctly after deleting the contents of $HOME/.glow
2 Run The first time a local calendar is created (during bootstrap), Glow should create an event “Welcome to Glow!” with a url to the Glow web-site, start-time now, duration 10 minutes
3 Feature-test Press the day, work-week (5-day), week, and month buttons on toolbar
4 Feature-test Double-click to edit a calendar event; change the summary; the event should be changed in the day view
5 Feature-test Open calendar using another client; check that the event change has been saved
6 Feature-test Create a new task in the task pane; mark it complete
7 Feature-test Exit Glow; re-start and check that all changes have been saved

Commit checklist
Id# Category Description
1 Coding Check Coding Guidelines
2 UI Check the UI Guidelines
3 Commit Add at least a 1-line comment to CVS for each file; combine related files into a single commit.
4 Build Glow must build in a new workspace created from CVS
5 Build Glow must build in an existing workspace after running 'ant clean'

Test Smoke test must pass