Differences between revisions 14 and 15 (spanning 2 versions)
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
April 2018: For a while, nothing much has been going on in the project. Meanwhile, the subversion tool is getting outdated in favour of git+github in the open source world so there has been requests to move the development environment to git+github. We outline the plans for this in the ["Github-based development environment"]
April 2018: For a while, nothing much has been going on in the project. Meanwhile, the subversion tool is getting outdated in favour of git+github in the open source world so there has been requests to move the development environment to git+github. We outline the plans for this in the Github-based development environment
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.
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.
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.