Views

Jajuk Members Guide

Welcome to new Jajuk members, have fun !

Contents

[edit]

Executive summary

Workspace of: Jajuk Members
Browse this workspace
Browse other Workspaces
Members Corner
Contacts
Contact us
Main Guides
Jajuk Members Guide
Active tickets (Trac)
Workspace's Tickets

Before starting to go through this, you must read Little guidelines of the perfect Jajuk member, create access account, subscribe to mailing list and RSS feeds.

[edit]

Project General Rules

[edit]

Team rules

We ask members to follow these basic rules:

  • Members are encouraged to create user accounts using same ID on:
  • Members have to communicate in English
  • Members have to subscribe on developer mailing list as it is the main communication stream
  • Members should give minimum progress information so we can build roadmaps
[edit]

Leaving project

  • Please tell us ASAP if you leave temporary or definitively the project. Members are considerated as inactive after a period of 3 months.
  • Former and current members list is available from this Jajuk Team
[edit]

Official Jajuk Members Roles and Guides

Jajuk members (see also Jajuk Team) can have more than one role. Jajuk members must follow this guide in addition to any other roles. Role can have one or more guides but main guide must be listed first. Guides can apply to one or more role.

Role name Role Description Main Role Guides
Documentation Manager Organizes and manages documentation, convert documentation in various formats. Documentation Manager Guide
Documentation Writer Jajuk documentation maintenance Documentation Writer Guide
Jajuk Members Any Jajuk Members Jajuk Members Guide
Java Developer Code features in the trac, (requires Java J2SE/Swing skills) Java Developer Guide
Media Designer Web and User Interface design Media Designer Guide
Packager Create packages for OS distribution Packager Guide
Project Admin Project lead manager Project Admin Guide
Promoter Public relation, publishing news on forums, download sites, keep them up to date Promoter Guide
Tester Jajuk qualification Tester Guide
Translator Jajuk user interface translation Translator Guide
System Admin Administrator of project's servers System Admin Guide
Systems Analyst Conduct written surveys, brainstorm, propose and chase features/tasks Systems Analyst Guide

Check out for open positions on Help Wanted page

[edit]

Communication

[edit]

Mailing Lists

  • For all members mandatory list is jajuk-developers
  • For developers and packagers, mandatory list is jajuk-commits (jajuk-tickets is optional and can be replaced by a RSS subscription, see bellow)
  • For translators, mandatory list is jajuk-i18n
  • For people in charge of support, mandatory list is jajuk-support
[edit]

RSS feeds

[edit]

Forum

[edit]

Wiki

  • This wiki should store all persistent information and guides on this project. It is the main developer portal.
[edit]

Trac

[edit]

Chat

  • Jabber is the default chat system, jajuk@conference.jabber.org is the default chat room.
  • For information, we recommend these jabber clients: Linux: Gaim, Kopete, Gajim; Windows: Pandion, Exodus; Java: Jeti and this Jabber server: jabber.org
  • Chat request: A chat request should be sent under the form of an e-mail on the developer list and contain at least following information:
    • [CHAT] <subject> as a title
    • [SUBJECT] <a detailled subject to speak about>
    • [INVITED] <some people, all the list, a group...>
    • [MANDATORY] <mandatory people>
    • [TIME] <date/time (don't forget to provide the timezone you use like UTS/GMT, PST, CET..)>
[edit]

Votes

If we are less than 7 active people in the team, the role owner should decide at the end even if the majority is against him. The other persons may not have the expertise to make a decision but everybody is encouraged to express their view. If the majority thinks the task leader is not capable and he is not going in the right direction, then he should be dismissed and a new one should be elected. If we have to decide on something there is no task leader, then we should vote.

We use the developer mailing list to send vote requests. Each request should contain following information:

  • [VOTE] in the message title
  • In the message body:
    • [SUBJECT]: theme and goal of the vote
    • [METHOD]: voting method of this vote. Standard voting methods are:
    • [DEADLINE]: Provide an ending date
    • [VOTING POPULATION]: Details people having the right to vote
    • [CHOICES]: Clearly identifies options that can be taken (A, B, C for ie)
    • [HITS] (recommended): Provide maximum of information to help people taking their decision (advantages/drawbacks for each choice for eg)
[edit]

Jajuk Brand Identity Guidelines

See the separate page Brand Identity Guidelines.

[edit]

Tickets (Trac)

Trac is web-based project management and bug-tracking tool. It allows users to create, view and assign tickets to Jajuk Members and developers. Tickets have the main following properties:

  • Type: the type of the ticket (e.g.: Bug, Feature, Task, Discussion, etc...)
  • Component: the project's part the ticket applies (e.g.: Java Developer, Packager, Tester, etc...)
  • Version: the version of Jajuk the ticket is related to
  • Milestone: the milestone version of the project the ticket is due to be resolved
  • Priority: the priority over tickets of the same component
  • Status: new (ticket waiting owner to take action), assigned (ticket owner has accepted to fix it), reopened, closed
[edit]

General Jajuk Teams trac rules

Jajuk Team has decided to apply the following rules to manage the tickets:

  • Please create a ticket of type task even for small ones as it makes project much more auditable and flexible
  • When closing a ticket: give a comment. If the ticket is referring to other tickets (especially for duplicate tickets), please give the tickets references in your comment. You can easily search for other tickets with trac search function.
  • Tickets not related to the Jajuk software should not have assigned version or milestone number. (Hence no version/milestone should be assigned to any other component than the "Java Developer" family.)
  • The Version of tickets with type: Bug, Limitation and Known issue must be set to the last production or earliest development version of Jajuk. Hence when releasing a new version, all these tickets will be moved to the new version (if they still apply).
[edit]

Creating tickets (new ticket)

New tickets from non members must keep the defaults options:

  • Type should be set to: Discussion
  • Component must be set to: (Jajuk Members) Any (Default Component)
  • Version must be set to your current version of Jajuk
  • Milestone must be set to: To Be Decided by Jajuk Team
  • Priorities must be set to: 5

Jajuk Team will be automatically notified of a new ticket and will decide of the most appropriate properties.

[edit]

Brainstorm tickets (also called 'Discussion' ticket)

Ideally all tickets should go through this 'Discussion' process when created. Discussion tickets should be seen as queue of tickets waiting to be discussed by the Jajuk team and then been appropriately configured. As soon as the ticket has been discussed by Jajuk members, the following ticket's properties must be set:

  • Type: must be set to the appropriate type (e.g.: task, feature, bug, etc..) hence must not stay as discussion.
  • Component: must be set to one of the "Java Developer" family when the ticket is related to the Jajuk software.
  • Milestone: must be either a specific milestone (e.g.: 1.5 "Lothlórien") or to a later milestone: To Be Decided by Jajuk Team. Milestone must stay empty only to tickets non-related to the Jajuk software.
  • Version: (if known) must be set to the last production or earliest development version of Jajuk that the ticket applies to. If the ticket is global (hence do not apply to a specific version of Jajuk), or if there is no actual code implemented about your ticket, do not set a version.
[edit]

Accessing trac ticket system

[edit]

Trac tools/plugin

  • A Trac XML-RPC access is available that can be used by Eclipse + Mylyn to get rich UI and automatic bi-directional access to tickets without moving from Eclipse. This connection is: <your trac login>/<your trac password> at https://trac.jajuk.info access-type:XML-RPC.
[edit]

Trac Administration

Manage Milestones:

  • A milestone must be created for only: the next minor version, any next major already decided version, and the development trunk.
  • The default Milestone must be set to "To Be Decided by Jajuk Team"
  • When releasing a new Jajuk version, the current milestone version must be closed

Manage Versions:

  • A version must be created per already released version
  • The default version must be set to '<nothing>' to force users to select a release
  • When releasing a new Jajuk version, the current version must be created
[edit]

Version rules

  • Jajuk releases follow this version scheme: <major>.<minor>.<fix>. Example: 1.1.4 : Fourth fix release of second minor release of first major release.
  • When begining a minor release testing process (about one or two months), we create a specific branch used for fixes (during this time, commiters can continue to work in the trunk). Example: one month before 1.1 official release, a "1.1" branch is created. All fixable bugs found against minor version are double-fixed in the release and in the trunk branches. For example, an issue discovered in 1.1 is fixed in the 1_1 branch AND in the trunk (1.2 development release).
  • Major and minor releases are maintened during a single minor releases (for example, 1.1 is maintened until 1.2 is released) and a fix pack release (x.y.z) is released ASAP if critical bug found or about every one or two weeks for minor issues.
[edit]

Code names

Code names rules follow:

  • One code name per major or minor release, not fix release
  • The code name should be a song title, preferably (but not mandatory) short and in English, can be composed of one or more words
  • 1.3 and 1.3.x releases are codenamed "My Dear Country" (Norah Jones, 2007)
  • 1.4 and 1.4.x releases are codenamed "Aerodynamic" (Daft Punk, 2001)
  • 1.5 and 1.5.x releases are codenamed "Lothlórien" (Enya, 1991)
[edit]

Release process

The Jajuk release process usually takes from 4 to 6 weeks.

  • The release process is announced with a message in the developer mailing list (make sure you subscribed to this list). The version branch is then created and all developments are then frozen in this branch (however, it is still possible to work on the next version in trunk). English labels are frozen as well to allow translators to start working.
  • Translators can complete their translations during the entire process. Note that translators can work on current releases even outside release process periods. Read the Translator Guide for more information about translation work.
  • Testers qualify and developers fixes bugs discovered during this period. See the Tester Guide. An e-mail is send on developer list at each Release Condidate
  • When we find the last rc stable enough, it is released as a final on Sourceforge and a maintenance branch is created. We wait at least 2 days between last RC and final release
  • The communication delegate sends the news in Freshmeat and other web sites after one week without critical issue
[edit]

User documentation

Jajuk is now a pretty large software using a few relatively advanced concepts like perspectives & views, logical / physical items, custom properties or devices. As a developer, you will obviously have to know and understand the application concepts. All of them are described in the User guide, please make sure to read it in deepth.

[edit]

Project initial specifications (2003)

Retrieved from "http://www.jajuk.info/index.php/Jajuk_Members_Guide"