I nominate this posting for "should be posted on meta". ----- Original Message ----- > From: "Tim Starling" <[email protected]> > To: [email protected] > Sent: Thursday, December 15, 2011 1:57:42 AM > Subject: Re: [Wikitech-l] Deployment process clarification? > 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
-- Jay R. Ashworth Baylink [email protected] Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
