Long Term Goals for the Chandler Community

v0.1 July 1, 2003

Hub assistance:

Current status: in Phase 2^? (Getting Acquainted) and Phase 3^? (Low Volume, High Focus) of Community Involvement

Goal: 1/2 or 2/3 of staff members have someone who is highly important to getting their work done. This help could be in

• design -- think BrianDouglasSkinner's volunteer assistance to Katie in the data model design and Andrew Francis' assistance to Andy with the agent and notification frameworks),
• "stressing our framework" -- think of Micah's noteliner work in its early stages),
• coding -- Micah's noteliner work if it ends up as part of our releases
• finding and reporting bugs,
• fixing bugs,
• improvement of our python, wxwindow code, etc.

Evaluation Criteria: We'll know this has become the case when:

• Staff person is uncomfortable implementing something big or making a critical decision without input from the volunteer(s).
• Involving these people is not seen as a burden, it is viewed as the chance of getting one's work done well.

Timing: Aim for 0.5. Needs to be after we have had some time to work through Phases 2 and 3 with some of our experimental cases.

QA and Testing

Current status: We are very early in Phase 1^? (Transparency) of Community Involvement. We're not doing much planned QA work, so there isn't much about which we can be transparent. But Morgen has made our rudimentary smoke tests and unit tests publicly available, so we are transparent with regard to the information we have.

Goal: 2/3 of staff feel that testing by non-staff is important to ensuring the code is ready for a release. This could include activities such as:

• do regular human testing
• develop and maintain the tests based on features we say we've implemented
• determine if bugs are reproducible
• test on specified builds for us (compiler issues?)
• verify something's fixed after Staff QA things so; do
• additional testing through use in their settings
• develop test cases.

Evaluation Criteria: We'll know this has become the case when:

• we want community testing to figure out what bugs exist; believing our own internal testing is not enough
  • community finds bugs that we don't already know about
• we want community evaluation of the overall "feel" in addition to our own evaluation

Timing for Releases: Assume we want the 0.5 release to be usable by early adopters on a daily basis. We need a strong testing community during the 0.5 development cycle. To have this, we'll need to start development early in the 0.4 development cycle. We might want to start earlier, but we shouldn't start later.

Timing for Milestones: Assume that the 0.3 release includes a set of features, building on the 0.2 infrastructure release. We don't plan to do a lot of testing for the milestones. But we do plan to do some testing, and we may want to do a lot of testing on the milestone or two before the 0.3 (and subsequent) releases. We may want to start a smaller QA testing program with volunteers later in the 3.0.x cycle.

Resources: We will need someone spending a good chunk of time on QA, if not devoted exclusively to it. This person needs to be on board for some period before a community QA effort is launched; trying to figure Chandler out and simultaneously lead a group effort will be painful. This person should spend some time getting to understand Chandler, doing some testing him or herself and then should start building a QA and testing community.

Localization:

Current status: Pre-Phase 1^? (Transparency) of Community Involvement. We are not far enough along with Chandler development to be ready for localization. We're not failing at tranparency here, it is not the case that we have information that isn't public. We haven't reached a point where we have useful information yet.

Goal: Chandler 1.0 available in X (10 ?) languages.

Evaluation Criteria: We'll know this has become the case when:

• localized versions exist
• localizers know the scope of the task before them
• localizers can work in Phase 4 (programatic involvement) of Community Involvement, where each one does not require specialized individual attention.

Timing for broad localization effort: Assume we want the 1.0 release to be available in multiple languages. We need to test out our localization results at least one development cycle before 1.0. To do this we'll probably want to have a much smaller program at least two cycles before 1.0.

Timing for small localization effort to test internationalization -- as soon as the internationalization code has been implemented. In this case I propose we look for one or two candidates for Phase 3 (Low Volume, High Focus) involvement.

Resources: We will need someone to coordinate the localization effort. This person would make sure we have the right set of information and tools for localizers (see http://www.mozilla.org/projects/l10n/mlp.htmlfor an example). He or she would also be involved in issues such as: are particular localizations "approved" by OSAF? Or do we host all versions and let users decide which are of good quality? How are changes requiring localization communicated to localizers? What do localizers need from devleopers? Unclear if this can be done by a volunteer, or exactly how much time it will take.

Spoke development:

Current Status: Phase 1^? (Transparency) and Phase 2^? (Getting Acquainted) of Community Involvement. (Counting Micah's work as hub development heading towards the superwidget, rather than development of alternative viewer parcels.)

Goal: non-staff members have written useful parcels. Could be:

• viewer parcels for importing and exporting data
• viewer parcels for new data types
• other?

Evaluation Criteria:

• number of parcels
• integration of parcels with Chandler framework
• others?

Timing: aim for 0.5, when we hope for adoption as dogfood by intrepid early users? Or sooner, to test the parcel framework and see what people are interested in? Also, we might want different timing goals for Phase 3^? (Low Volume, High Focus) and Phase 4^? (Programatic Involvement) of Community Involvement.

Resources: We need to provide some assistance to people to help this happen. I haven't scoped out how much this could be, or come up with a way to evaluate competing opportunity costs.

Evangelism:

Current Status: Phase 1^? (Transparency) of Community Involvement.

Goal: a set of passionate users who encourage others to use Chandler.

Evaluation Criteria: [ask Pieter for some help here]

Timing: 1.0.

Resources:

Someone from the OSAF marketing side of the house might want to focus attention here. A great product will do most of the legwork here, but there will undoubtedly be things OSAF can do to make the results of user evangelists more effective.

Documentation

Current Status: Phase 1^? (Transparency) of Community Involvement. We post what we have, but it isn't much. Not ready for others to get involved documenting our work..

Goal: some set of docs not written by staff. Evaluation Criteria:

• docs appear
• they are useful and not too inaccurate
• volunteers edit our docs

Timing: 1.0.

Resources: Two choices.

• No resources here, and see what develops. Both XUL Planet and mozillazine provide enormous benefits to the Mozilla community with no direction/ assistance from mozilla.org staff.
• We devote some resources to hooking would be documenters up with developers. Perhaps we focus on the end user side which is easier to document without living among the developers.

-- MitchellBaker - 01 Jul 2003