ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
ChiliProject "spread the word" presentation
Based on the relatively small mindshare ChiliProject currently has in the Rails and general Ruby "population", I want to find axes for a ChiliProject-centered presentation to spread the word about the fork, explain it, gain mindshare and visibility and maybe win one or two devs over to help. The purpose of the to-be presentation is not to explain (longer than 3 minutes) what ChiliProject does as the assumption is most of the audience knows about Redmine, nor is it intended to be a training for people who already use it ("did you know about our awesome right-click menu on the issue list?") but to gain mindshare, visibility and new devs.
Now here are the general ideas I worked into my previous presentations:
- Why fork?
- Community reasons
- No clear roadmap/vision: versions get dates and suddenly don't have anymore, there is no "clear" rule what goes in what verson, there's no communication about what to expect from future revisions. This is frustrating for users as well as for fellow developers who are not always (ever?) taught about those changes.
- No community management: Communication with the community happens through news and occasional forum posts, the latter coming nearly exclusively from committers/developers rather than the "lead", the committers/developers can most of the time only temporize though as they often don't have more information than the rest of the community.
- Next to no communication: Communication with the project lead is difficult at best, non-existent most times. Example: I have been promoted committer without even being notified about it, I have been made administrator of redmine.org only on "want to?" "yeah, why not?" without anymore guidance, dos and don'ts or a clear communication channel to hit in case of problems/uncertainties.
- No visible interest in fixing it: When confronted with them the problems seem to have just been ignored, any proposal to help remedy the situation hasn't received the necessary attention or "authority" for it to bear fruit.
- Technical reasons
- No technical "guidelines": I don't really see any commit, code or "style" standards or even (constructive) criticism other than "just commit it" or "does some rework and commits it without giving feedback to the committer".
- Split response to refactorings: Ok, so I'm not that sure about that one anymore because this argument was tainted with backstory/bad blood, but the fact is that we still have rails 1 (and probably even pre-1) code.
- Erratic versioning: The versioning is hard to follow or predict making it harder for admins/packagers to know "what they get".
- No real security management: security issues are often fixed on trunk potentially divulging them early, and the fix might sit on trunk months before being released as part of the next best version coming along.
- Community reasons
- How does ChiliProject address those problems?
- Clear and open governing structures,
- Adherence to the "Free and Open Source Ideal",
- Planned development and releases,
- Community involvement,
- Responsible disclosure and timely security releases as necessary.
- (or at least we try hard)
- Chalenges ChiliProject faces
- Big codebase: on Holger's count we're at ~41000 SLOCs (down 5000 from Redmine) with a more or less 50:50 code/test split. We've shaved 10% off, we can go further, less code for us to maintain.
- Old codebase: and edit action through post and Controller actions that test if they are post or get. That was fine years ago, there's newer best practices though.
- Not Invented Here parts: there's a not insignificant portion of the code that tries to solve already solved problems that should probably be phased out to work with externally maintained gems/libs.
- Vendored gems: some gems have been vendored and patched "to death", coupling them to the app and making updates harder.
- What we've achieved
- s/svn/git/ (yeah, the switch to git as the main repo was a middle-ish interest to some)
- Ruby 1.9 (except for some last-minute edge-cases)
- Rails 2.3-latest
- Security releases
- What's next? (3.0)
- New design
- Liquid for formatted text
- Separate mails instead of (B)CC-ed mails for notifications
- reposman as a gem (OK, maybe not quite for 3.0)
- API work
- And then?
- Rails 3.1
- Tentative JRuby support
- More API work
Ok, this turned out a little longer than I had thought.
The topic I wanted to work into this for future talks/presentations is that the Ruby and Open Source community in general need and deserve a better general-purpose project management system (as opposed to e.g. GitHub which does great on Code, OK-ish on issues/milestones, but can't really be used for anything else than code or onsite except for big money), with examples of how it is used by non-technical teams at some of our clients' or even adapted by us to accommodate another use-case than "pure" project management (not official yet) (yeah, those are examples from finn, but that's the ones I know about, I'm happy to hear of more). This topic would need some research into "competing" products like trac, jira and maybe basecamp and so on to be complete and credible though.
Any more ideas you'd want to see in stuff like that?
Oh, among the reactions and subsequent discussions I had after the talk on thursday at the RUG::B (Ruby User Group Berlin) was one very interesting and I think good piece of advice: pick out some actual problems we're working on now or we'll be working on next so that potential devs in the audience can get a better grasp of the work at hand which should lower the "barrier of interest" to have a look at the project and maybe contribute.
Currently that would be: change the mailer from on CCed mail to individual mails (that's mostly finished, but a good example of smaller things that need fixing nonetheless), reposman into a separate gem (might be interesting for someone rather interested in smaller code projects), the authentication+authorization API (e.g. needed to remove the specialized code in Redmine.pm), refactoring controllers from rails 1-ish to current rails conventions (and other things than controllers, but I think controllers need it the mostâ€¦), a good API concept in general.
Any others you think belong in this list?