Navigating the code development process (part 2 of 2)
While at JAB11 in May, I heard comments from more than a few developers that it could be difficult to get their code accepted into the Joomla! core. So I committed to publishing a JCM article to try and address those concerns. In the first article of this two part series, I gave an overview of how the existing development process works. In this month's article, Mark Dexter and Louis Landry from the Joomla! Production Leadership Team have responded to questions about the development process that were submitted by other developers in the community.
Do you think there's room for improvement in how the Joomla! idea pool website at http://ideas.joomla.org is being used? If so, what are your thoughts on that?
Louis: There is always room for improvement. I think the first thing that would help is having people actively maintain the site. We've taken a step forward on that by inviting Rouven to be an administrator and I think that getting more people interested in moderating that site would be great.
Mark: I agree with Louis. More active management will help, and we have Rouven and one other volunteer working on this.
Do you think the current Joomla! idea pool website has a bias toward older ideas that have been in existence longer and so have had more time to get more votes, compared to newer ideas that haven't had as much time to get votes? If so, do you think there's any practical way to overcome that bias? For example, could the "Hot" tab be given some extra attention when looking at what the theme for the next major release will be, or what features might be given preference for being included in the next major release?
Louis: I think the ideas pool is biased towards what is on most people's minds. It is always more difficult to get your new ideas visibility. That is just one of those facts of life we have to deal with. In those cases I think it makes a lot of sense to be active on the mailing lists and in the tracker talking about what you are doing or want done. The idea pool is not the only communication stream available, but it is a good one. I do think there are opportunities to improve how the site is managed as I've said in the previous question, but that is something that I would largely leave up to those managing it.
Mark: I think it is important to keep in mind that the Ideas site is only one of several sources for enhancement ideas. In my old company, I used to talk about 4 sources of enhancement ideas: (1) customers; (2) our developers; (3) sales & marketing (feedback from prospects); and (4) the overall industry (competitors, trends, and so on).
I think our process is or should be somewhat similar. We hear from existing users via Ideas, forums, tracker. Our contributors contribute their ideas. We hear from community members who are competing with other packages. And hopefully the PLT and others are keeping an eye on the industry and trends.
Are submitters required to run unit tests before their code is added to the main tree? If not, do you think that would be an improvement in the overall code development process?
Louis: This is something that we definitely are looking for more and more. It is already a part of our development strategy as can be found on the development site. I don't think we are yet in a position to be absolute sticklers on unit tests for all things, but it is something that we strongly encourage. If there are two things we are looking at to add into the codebase and one of them has unit tests written you can bet the farm on the fact that we'll go with the unit tested one nearly every time.
Mark: In a perfect world, everyone would be submitting a system test or unit test for any bug fix or code change. However, especially the system test aspect of that is not realistic at the present time. However, we should be working in that direction.
What do you think of the idea to create a "WIP Log" that details what features are being worked on by whom, and possibly a metric on readiness (for example "Dev", "Alpha", "Beta", "Stable")? If we could implement this, then different feature sets can be worked on by self-organizing teams, with one person from the team delegated to update the status and one "official" repo for the current state of the project.
Louis: That sounds an AWFUL lot like our feature tracker.
Mark: Agree with Louis.