On 15/12/11 12:05, Ian Baker wrote: > Hi, everyone. I'm looking for some clarification about the process whereby > code gets deployed on the Wikimedia cluster. Not so much the technical > side of things, and in fact, I'd love to keep this conversation > VCS-agnostic. We'll be moving to git soon and things will change, but > these questions apply regardless. > > I've been working to review a new extension that Petr Bena wrote, > InteractiveBlockMessage. It's a simple little extension that adds some > template magic for blocked users, to facilitate the creation of less > confusing talk page templates. This bug has links to the relevant code and > on-wiki discussions: https://bugzilla.wikimedia.org/show_bug.cgi?id=32819
Usually an experienced developer, most often with shell access, needs to champion a contributed extension if it's going to be deployed. Championing can be a long and complex process. There is no written policy that says this, and maybe it's not ideal, but in my experience, it's how things work. A champion associates their name with an extension. They become a maintainer and point of contact for any problems with the extension after deployment, especially if the volunteer is not available every day. So championing usually begins with an initial cycle of code review and improvement, to get the extension to a suitable level of quality so that maintenance requests after deployment won't be excessive, and so that the champion's reputation won't be at risk. A champion is usually a WMF staff member, so the champion will need to convince their manager that spending time on the extension is a good idea, and that the extension will be useful to deploy. Staff member or not, the champion needs to convince relevant stakeholders, such as senior developers and the ops team, that the deployment should go ahead. The champion is ultimately responsible for community consensus-gathering (if necessary) and announcements, but they may be able to delegate these tasks to the extension creator. That done, the champion will perform the actual work of deployment, such as scheduling, merging to the deployment branch, and configuration. After deployment, the champion's role as a maintainer begins, which may include deploying any urgent updates provided by the extension creator, and discussing bug reports. It's a lot of work, and it's undervalued, maybe because we've never discussed this process openly. We like to think that there is some queue that extensions go into, and that the extension will slowly make its way to the front of the queue and be deployed. In practice, an extension will only get to the front of the queue if there is a champion in front of it elbowing people out of the way (figuratively speaking). It sounds like you want to be the champion for InteractiveBlockMessage. I think it's excellent that you want to get into that line of work. I'd be happy to give you advice and to help you with the process. It's not a problem that you don't have shell access at the moment, you can just apply for it. > Process B is what I'm used to, but it seems that for this extension, it's > process A. When do we pick one or the other? Is process A for > community-contributed code, whereas B is for stuff from WMF? Do things > change when we're deploying a whole new extension? I understand that this > process is informal, and I'm not necessarily pushing to formalize it, but > maybe a few general guidelines or a minimum standard would help make things > more clear. I have been hearing a lot of resentment from community members about the features team deploying extensions without properly consulting the community, let alone building consensus. My recommendation is that if you want to deploy an extension which is likely to be even slightly controversial, you should seek community consensus, regardless of who you work for. Running a well-publicised straw poll is a useful and rewarding experience. You'll get a huge amount of design input. > The step where Someone Who's Been Around A While reviews the code makes > sense, but it seems to be applied inconsistently, or perhaps the conditions > for that just aren't clear. When does code need to be run past one of > these very busy people, and when is it okay to push it without? Is there a > way to indicate which code needs this review, and when it's done aside from > the existing 'OK' status in CR? Secondly, who *are* these people? I've > heard Roan and Tim so far, but I bet there are more. It depends on the nature of the extension. Some extensions need special skills to review, such as performance analysis, security, UI design or languages other than PHP. Senior developers tend to have accumulated more of these skills, but nobody knows everything. You should try to make sure that every aspect of the extension is reviewed by someone competent, even if that takes multiple reviewers. There's no official list that I'm aware of, so you'll have to ask around. In terms of strict policy, I think it's OK for a deployment to proceed as long as it has been approved by your director or equivalent level manager. The point of gathering reviews from experienced developers is to reduce the risk of something going wrong, and to improve the quality of our output. I don't think we need to encode the review process as law. > Is a discussion on wikitech-l generally part of the process in addition to > the on-wiki discussion? Is that only for new extensions, or for other > types of deployment as well? Yes, wikitech-l is generally part of the process, both for new extensions and for other deployments. Wikitech-l is for developers and technically-oriented users, whereas on-wiki discussions will reach general users. I think wikitech-l is more important than an on-wiki announcement, because interested users will copy important announcements from wikitech-l to their home wiki (e.g. to the Signpost), but there's not such a strong information flow in the other direction. -- Tim Starling _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
