Add this page to your book
Remove this page from your book
Table of Contents
Snarfburs Development Wiki
This is a Wiki for documents around the developments of Snarfbur and other who like to support this projects.
It has 3 main parts for each project:
- General Overview about purpose, status, resources, …
- User Guide / Handbook
- Development Documentation
The general guidelines for:
- Project Management
- Project Development
- Project Documentation
- Project Maintenance
And the mandatory pages:
Of course not everything will be there at start and other things will maybe added later.
Why not an own domain?
Thing Big - Start Small
As long as there are mostly only me, this will be a good starting point with a small effort.
If it will grow to a small group of people we will move it to another domain. By that time, we will hopefully find a good name, so that more people can find us and we can grow.
My homepage is in German, so why changing the language?
Different target groups. My homepage is mostly for my friends and for 'Germans'. My development projects are much more international and I hope that in this way, I can reach more persons to use it and maybe support it.
Feedback & Whishes
Even a small 'Thank You' is better then no feedback. Do not hesitated to share problems, or comments like: 'I will not use it, because …'. If you miss a feature, tell us.
But please, mention the project name and the version in the subject and write currently to: firstname.lastname@example.org
How can I support?
There are many, many ways to support one or more projects, even if you are not a developer
- Feedback & Whishes: Yes, this is already a support
- Tester: The product of a project would be much more stable, if it would be test by another person before it is released.
- User Guide Writer: A user guide written by a user, not a developer is most of the time much better to understand from other users
- Developer: There are many roles in which you can support us. Develop new features is only one role of a Developer. Automatic Tests, Bug finding & fixing, Code review, … are also roles in which a developer can support the projects.
Things, where everybody should be able to commit will use we in the text.
Since this should be an agile group, this things can be changed, if the group members want to change it. Refactoring and getting better is a main part of agile behavior, as are group instead of leader decisions. (Of course there are exceptions, but this will be part of the general guidelines).
A name should be used, if the text represent a personal opinion. Since it is for most persons (like me) hard to write in 3rd person, you will be accouter also I. Please check the author & history of the page to identify the person if this is imported for you.