Since there are more than two people working on wikipbx codebase, I think that we should stick to a bit more disciplined approach for commits. There are various ways to organize workflows, I'm thinking about something inbetween "Decentralized with shared mainline" and "Decentralized with human gatekeeper". Unless it's a trivial change that can be committed directly to trunk by anyone, it should go through the following stages:

1. Create or select existing bug or blueprint. If it's been created, wait for some feedback.
2. Make a branch for this task. Link the related bug/blueprint to it in LP interface.
3. Hack, hack, hack.
4. When it's ready, it should be reviewed by someone (not the person who wrote the code). If there's something to be improved, go to #3.
5. Merge with trunk and/or stable branch.

Things to look for during code review:

1. Python coding style violations.
2. Things that can be improved.
3. Errors, typos.
4. Possible unexpected effects from the new code.

On a serious note, github is intended for hosting code rather than developing software projects, so it doesn't offer much besides a fancy UI for forking git repos. What's missing: release planning and localization. This also leads to oversimplified issue tracker that most people don't use.

As a bonus, you can host packaged software in PPA, which I'll probably do for 0.9.

I mean github has a ton of momentum, it seems like a better time investment to learn git/github.. what do you think? What are the major benefits of launchpad over github?

I've already created a branch there a few days ago, although I was going to use it only for translations initially. I'll post a message with more details in this forum when it'll be ready for development, stay tuned.

Is there any particular targets set for the new version?
What new functionality are planed for the new version?

The next version will work with a recent version of Django plus some other minor tweaks like UI improvements

How far are the project right now from the next release?

Its about 90% there

What is the best way to contribute to wikipbx project?

There's currently not really a good way .. if you have code patches send me a private message and we can discuss over email. Eventually I think DVCS might be the best approach.

How stable is the current trunk version? Can it be used in production, if not what areas are not stable yet.

Its stable, I can't think of any areas where it will blow up on you..

I'm also thinking that DVCS is much more appropriate, because that way people don't have to send in patches which puts pressure on us to review .. with DVCS people who want to submit patches can just fork it and we will pull the (good) changes.

I think it makes sense to move everything somewhere else :)

Someplace that ..

• Free for open source projects
• provides DVCS, ideally git IMO
• Nice issue tracker
• Forum / Wiki

As there are just two developers and we work on it in our free time, we don't have any deadlines except "when it's ready".

The primary goal for the next release was to get wikipbx running on modern version of django and it's been completed. However, we don't consider trunk production ready yet as it hasn't been extensively tested and there are some more features planned.

I'm new to this project and would like to find more about its development.
Could developers share the current status of wikipbx development. I'm interested in the following aspects:

Is there any particular targets set for the new version?
What new functionality are planed for the new version?

How far are the project right now from the next release?

What is the best way to contribute to wikipbx project?

How stable is the current trunk version? Can it be used in production, if not what areas are not stable yet.

Thanks!