Erik Moeller wrote:
Following initial conversations, the purpose of the meeting tomorrow is to do a deep-dive into a specific problem set: the code review, deployment and release management process. We'll be digging into questions like:
- What are the best methods to ensure we keep up with the backlog
while still maintaining a good clip of WMF priority development; 2) What's a realistic deployment and release cycle to shoot for (for trunk, extensions, branches); 3) How do we dissipate key skills more widely among both staff and volunteers (e.g. deployment, security reviews); 4) How/when can we split "big hairy projects" with integration issues into more manageable chunks; 5) What other high priority improvements do we need to prioritize (e.g. increased test coverage, improvements to the testing frameworks, het-deploy, staging environments, etc.)
We're intentionally keeping this first meeting at a manageable size to have a high face-to-face throughput and to explore where ThoughtWorks can best help us. But I'm very much intending to make our thinking public, and to form clear and visible groups around core problems we're tackling, just as we have been doing with all WMF engineering projects. So, I'll keep you posted, and if you have thoughts that you'd like to post ahead of time, please do it onlist or offlist :-)
Thanks very much for the heads-up. Posting the minutes or any notes from the meeting on Meta-Wiki or mediawiki.org would be fantastic.
I might say that one more point to focus on specifically is to how to leverage volunteer development (this is hinted at in some of your five points). There are _a lot_ of people who are capable of coding in PHP and who are willing to donate their time and talents, but Wikimedia/MediaWiki code development has chased them off, generally through neglect (patches sitting, review sitting, etc.). If there are ways to specifically look at that, it would be an enormous benefit to Wikimedia/MediaWiki, I think.
Much like the wikis themselves, you can rely on people to do good work if there's a support structure in place. The only caution is that, of course, if patches and commits increase without additional review/deployment support, you just make the problem worse (backlogs and frustration grow). Still, it seems that a huge issue is that volunteer time and talent is being wasted, so I think that's a fairly high priority (or at least should be).
I'm really glad that these issues are being looked at. I know that a lot of people in the community (end-users and people related to the software development) have become frustrated with the speed of code review/development/time-to-new-features, so any step in a better direction is fantastic. :-)
MZMcBride