keryx team mailing list archive

[Douglass Clem <crashsystems@xxxxxxxxx>]

Chances are you have thought about  this. However, I think reiteration might
be useful. I'm going to outline what seems to me to be the two biggest
barriers to code contributions to the project. I think addressing both
points should be a goal for the 1.0 release.

*Where is the code base?
*For someone who wants to contribute code to a project, being able to see
the latest version is essential. This is probably the reason behind the
mantra "release early, release often." Development is difficult when you
commit infrequently (relative to your progress on the code), and when you do
commit it introduces huge changes to the code base. A higher amount of
fluctuation is of course going to be the norm on a very new code base, as we
have with 1.0. However, I think this can be mitigated if we institute a
policy of pushing our code changes at latest within 24 hours of when they
are made. Often times these changes won't be ready for the main code base,
so I think this is a perfect opportunity to utilize personal branches that
are synced with devel as often as practical.

*Where is the project going? What are the development plans.*
This has already been discussed on IRC, but I think it is worth repeating.
To develop as a group the group needs to know in detail where things are
heading. Yesterday we got a
wiki<http://keryxproject.org/wiki/index.php?title=Keryx1.0>up and
running, and I think its a great tool for planning. Before another
line of code is written, I think we need to have a detailed set of goals we
agree upon (note: these goals will tie in closely with the unit tests). Once
we have the goals set, lets move onto planning how 1.0 will work. I believe
that these plans should start off at a very high level of abstraction, and
then move onto increasing levels of detail until the plan can have a nearly
one-to-one correlation to items in a todo list. This level of planning,
along with good unit tests, will make it so that individual parts of 1.0
will be easily able to be written by multiple developers. IMHO better
planning == easier collaboration between devs.

--
Douglass Clem
Chief Technology Officer,
Crashsystems LLC (crashsystems.net)
Public Key: 37F9 E685 576A CFD3 B08C