Mailing List Archive

Deployment process clarification?
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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Deployment process clarification? [ In reply to ]
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]
> 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.
> [....]
> [Process B]
> 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.
[....]
> 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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Deployment process clarification? [ In reply to ]
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
Re: Deployment process clarification? [ In reply to ]
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

--
Jay R. Ashworth Baylink jra@baylink.com
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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Deployment process clarification? [ In reply to ]
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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Deployment process clarification? [ In reply to ]
On Wed, Dec 14, 2011 at 10:57 PM, Tim Starling <tstarling@wikimedia.org>wrote:

> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l