First of all, thank you for the transition from svn to git repository. After steep learning curve, I've come to like git for the ability to have own hacks in own repository and ability to easily create patches for community.
As a new contributor, I have some ideas about things that could be done better. I'd like to hear your opinions about them:
- Mailing list: I don't know, if one exists yet but at least I have not find one. Developer mailing list would be useful for sending patches to codebase, as other subscribers could review the patch and give their comments. On the mailing list, people could also tell what they are working on, to prevent for example many people fixing the same bug.
- Share info about upcoming things regularly (once a week or month?). I heard yesterday Oborne mentioning that mavlink protocol is going to change. It would be great hear beforehand about this kind of "big news".
- Publish milestones for major releases. This point may overlap with previous, but people other than developers might want to know what's coming up.
- Currently there is a nice list of developers on diydrones, but there could be listed responsible persons who to contact about access rights to repository or issue tracker.
Replies
Janne,
There are a half-dozen dev mailing lists and weekly dev calls, but we've made them invitation only so far for a few reasons:
1) The volume of email is huge just with the existing dev teams and we're not sure we can handle more traffic through that method. That's what this social network is for.
2) We discuss upcoming hardware in those lists, and because that has commercial implications we need to keep it in a closed group until we're ready to release. Huge investment goes into hardware products and progress is unpredictable. Sharing that sausage-making would both confuse and probably kill the market.
That said, we are moving towards a process that makes it easier for people to contribute. We've moved to the Git version control system, so people can work on code in a local repository and contribute patches in a way that's easy for the dev team to evaluate and integrate.
We're also going to open some of the dev lists, at least to in a read-only form. We just need to clense them of all hardware discussion, which is big job given the volume of the archives.
Back to your points:
--MAVlink is indeed changing (we're part of that, so we'll be ready on day one). The MAVLink dev team is here.
--We have published roadmaps in the past, and we should probably do it more regularly. Just another one of those jobs we don't have enough time for, but I take your point and will try to get one out soon.
--Everyone has access to the Issue Tracker already.
--The way most people come to be invited to the dev team is by proposing to add/fix something in particular and showing that they are competent to do it. One great method is to pick off some bug report in the Issue Tracker and either fix it or prove that it's invalid. That's a great demonstration of a good fit in the project, and we can integrate that person more easily into the existing dev team structure.
Overall, I very much take your point and we're working on ways to make it easier for people to contribute. Moving to Git was for exactly this reason, but we've got a lot of work still to do. The cost of bringing in people in the wrong way is high (everything from time spent bringing them up to speed to the risk that they'll mess up the code), so we have to be thoughtful about how best to do it.
Maybe you can join the project as our New Developer Ninja and help us with this ;-)