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
Here's my present understanding of the process for community-contributed code:
1. Discussion happens, a need arises, etc. 2. Someone writes some code, probably in the form of an extension 3. That extension is checked in and makes its way through code review. All revisions must be ok'd to deploy. 4. On-wiki consensus is reached regarding deployment, and the discussion closes. 5. A ticket is created to request deployment on a specific wiki 6. Someone Who's Been Around A While (Tim, Roan, maybe others) looks over the code and decides it's okay 7. (maybe) A discussion regarding the extension happens here on wikitech-l. 8. The ticket gets picked up, extension gets deployed, ticket gets closed.
(Of course, I'm probably getting this wrong and I'm sure the steps are out of order. Please correct.)
This differs rather significantly from the deployment process we've been following for new code here in the office. That's more like:
1. Someone decides we need the code. 2. The code gets written 3. Code is checked in, makes its way through CR, must be ok'd before deployment 4. A deployer schedules a window and deploys it.
Note that I'm leaving out the technical parts (creating a patch, pushing to prototype, testing, etc...) That's unnecessary detail here. This message concerns only the social part of the procedure.
My specific questions:
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.
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.
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?
I would love to get this worked out and document it, so community developers can better understand how to get their code deployed. Of course, if this is already documented somewhere please send me a link. :)
-Ian
Hi Ian,
Thanks for sending this mail! (I prodded him to do it in a private thread run amok)
More inline...
On Wed, Dec 14, 2011 at 5:05 PM, Ian Baker ian@wikimedia.org wrote:
[Process A]
- Discussion happens, a need arises, etc.
- Someone writes some code, probably in the form of an extension
- That extension is checked in and makes its way through code review. All
revisions must be ok'd to deploy. 4. On-wiki consensus is reached regarding deployment, and the discussion closes. 5. A ticket is created to request deployment on a specific wiki 6. Someone Who's Been Around A While (Tim, Roan, maybe others) looks over the code and decides it's okay 7. (maybe) A discussion regarding the extension happens here on wikitech-l. 8. The ticket gets picked up, extension gets deployed, ticket gets closed. [....] [Process B]
- Someone decides we need the code.
- The code gets written
- Code is checked in, makes its way through CR, must be ok'd before
deployment 4. A deployer schedules a window and deploys it.
[....]
My specific questions:
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?
Not all community-contributed code has been subjected to process A, and not all WMF-developed code has skated by on process B. However, it's true that it generally looks a lot harder for community-contributed stuff to make it through.
It basically boils down to this: does the person deploying it feel comfortable deploying it? Well, here's what they're afraid of: a. Is this something that is going to melt down the servers on my watch? b. Is this something that is going to open up a big security hole in the site? c. Is this something that is going to cause a lot of editor/reader angst and drama? d. Is this something that runs against some WMF policy, stated direction, or unstated preference by one of the powers that be?
Process B is generally the process that occurs when the person deploying it isn't terribly afraid of any of the above. If you find yourself in process A, chances are, it's because the person deploying doesn't feel like it's been vetted to the degree necessary that they're going to put themselves on the line by deploying it.
I've got more thoughts, but rather than trying to get everything in one email, I'll stop and send now.
Rob p.s. I'd suggest a separate thread about InteractiveBlockMessage, rather than lumping it into a meta conversation about deployment process.
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
I nominate this posting for "should be posted on meta".
----- Original Message -----
From: "Tim Starling" tstarling@wikimedia.org To: wikitech-l@lists.wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Tim and Ian, thank you for mail,
I would like to note that for both extensions I am working on I already received a support from community, both were announced and one was even mentioned in Sign Post, the discussion on Proposals board was closed for both of them in favor of installation to english wiki. So I don't think there is a need to notifiy community again.
----- Original Message -----
From: "Tim Starling" tstarling@wikimedia.org To: wikitech-l@lists.wikimedia.org 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:
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.
On Wed, Dec 14, 2011 at 10:57 PM, Tim Starling tstarling@wikimedia.orgwrote:
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.
[etc]
Just a quick update, since it's been a couple days:
Tim, thanks for posting and clearing this up. I really appreciate it. I'm working on a couple drafts for either meta or mediawiki.org (not sure which is most appropriate, but I think that'll be clear when they're more written), which explain this process and link to tools for navigating it.
-Ian
wikitech-l@lists.wikimedia.org