Login | Register
My pages Projects Community openCollabNet

argouml
Wiki: Diff for "Strategic Planning"

Edit this page | Links to this page | Page information | Attachments | Refresh page

 

Differences between revisions 11 and 14 (spanning 4 versions)

Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

== Releases ==
To keep the project going we need to make frequent releases.

Plan: At least one release of any kind each month.

Plan2: At least one stable release every 8 months.

For the current plan, see ReleaseSchedule.
Line 5: Line 14:
Some important areas are identified, but no agreed plan so far. Some important areas are identified:
Line 8: Line 17:
Line 9: Line 19:
 * ["UML 2.x support"]
 * ...
Line 12: Line 20:
== Plan for contents of upcoming releases ==
For details, see ReleaseSchedule.

=== Release 0.30 ===
When: October 2009?

Big picture:
Line 21: Line 22:
["ReleaseSchedule/0.30_Development_Releases"]

=== Release 1.0 ===
Winter 2009/2010?

 * Undo
 * ["Undo"]
Line 30: Line 25:
No agreed plan.
We want the project to be alive and evolving with respect to contributing developers and users. What we do for this is:

 * '''Release often.''' Hopefully a lot of buzz is created around the project if it is known to produce releases regularly. Stable releases serve for modeling projects in production, we encourage to always upgrade to the newest stable release. Developer releases are for experimental use only and demonstrate the development progress.

 * '''Talk about it.''' The project homepage is a well maintained central with links to all our communication channels. We publish news items and release plans regularly. Our development discussions are always public and online available. Team members post in many networks (forums/blogs/mailing lists) worldwide. We have a developer wiki. And we encourage users to build a community by mainainting separate web resources for users: a wiki and a forum.

 * '''Offer support.''' The team can be contacted at any time through mailing lists, both by users and other developers. We maintain a bugtracking system where anybody can report defects and enhancement/feature requests. Top priority here: any request will be answered!
Line 33: Line 35:
No agreed plan. By releasing often, we show activity and attract developers.
Line 35: Line 37:
== Cooperations ==
No agreed plan.
Each new developer can start by fixing their favorite problem in ArgoUML first. There is a lot of complex code and new developers need a lot of determination to learn enough to be able to do anything.
Line 38: Line 39:
== Mission statement ==
No agreed plan.
== Collaborations ==
Discussions start on the dev mailing list. If the collaborating groups discussion is becoming too specific and the topic is within the scope of one of the ArgoUML subprojects, move to the dev list of the subproject. If not, move to private mails, or a new mailing list created for the purpose. It is a good idea if someone would summarize the discussion, weekly, on the dev list.

If mail is not suitable for the discussion, use whatever mean available (netmeeting, irc, skype, phone, ...). Summarize to the dev list.

Create plans and discussion material in this wiki. If document interchange is required either put them up as attachments to the wiki or check them into the ArgoUML subversion repository.
Line 42: Line 47:
No agreed plan. Project Leader to keep the project together.

Appointed developers are leading the work with each subsystem.

Release Responsible manage releases.

Everybody find their own tasks to work with. Preferably from the important areas above. The appointed developers act as guides.

Releases

To keep the project going we need to make frequent releases.

Plan: At least one release of any kind each month.

Plan2: At least one stable release every 8 months.

For the current plan, see ReleaseSchedule.

Direction for the development

Some important areas are identified:

Promoting the project

We want the project to be alive and evolving with respect to contributing developers and users. What we do for this is:

  • Release often. Hopefully a lot of buzz is created around the project if it is known to produce releases regularly. Stable releases serve for modeling projects in production, we encourage to always upgrade to the newest stable release. Developer releases are for experimental use only and demonstrate the development progress.

  • Talk about it. The project homepage is a well maintained central with links to all our communication channels. We publish news items and release plans regularly. Our development discussions are always public and online available. Team members post in many networks (forums/blogs/mailing lists) worldwide. We have a developer wiki. And we encourage users to build a community by mainainting separate web resources for users: a wiki and a forum.

  • Offer support. The team can be contacted at any time through mailing lists, both by users and other developers. We maintain a bugtracking system where anybody can report defects and enhancement/feature requests. Top priority here: any request will be answered!

Recruitement of new developers

By releasing often, we show activity and attract developers.

Each new developer can start by fixing their favorite problem in ArgoUML first. There is a lot of complex code and new developers need a lot of determination to learn enough to be able to do anything.

Collaborations

Discussions start on the dev mailing list. If the collaborating groups discussion is becoming too specific and the topic is within the scope of one of the ArgoUML subprojects, move to the dev list of the subproject. If not, move to private mails, or a new mailing list created for the purpose. It is a good idea if someone would summarize the discussion, weekly, on the dev list.

If mail is not suitable for the discussion, use whatever mean available (netmeeting, irc, skype, phone, ...). Summarize to the dev list.

Create plans and discussion material in this wiki. If document interchange is required either put them up as attachments to the wiki or check them into the ArgoUML subversion repository.

Organization

Project Leader to keep the project together.

Appointed developers are leading the work with each subsystem.

Release Responsible manage releases.

Everybody find their own tasks to work with. Preferably from the important areas above. The appointed developers act as guides.

Strategic Planning (last edited 2009-11-25 09:22:48 -0700 by thn)