In description:

In recent history, TPG hasn't been notified of phabricator changes. However I think it would be healthy to asses ways to vet updates and give TPG and engineering team leads advanced notice.

1. T120013: Next Phabricator Upgrade - 2016-02-18 with links to past tracking tasks eg: T110443 and T108142
2. I don't think we need to give all engineering leads advanced notice of Phabricator upgrades. is there a specific problem you are trying to solve here? If it's about watching what is coming down the line regarding Projects V3, then watching the work upstream is the best place to do so.

1. T120013: Next Phabricator Upgrade - 2016-02-18 with links to past tracking tasks eg: T110443 and T108142

This is helpful. would you mind providing more information on (how to find these tasks, the boards they live on etc) in the phabricator wiki pages:
https://www.mediawiki.org/wiki/Phabricator

2. I don't think we need to give all engineering leads advanced notice of Phabricator upgrades. is there a specific problem you are trying to solve here? If it's about watching what is coming down the line regarding Projects V3, then watching the work upstream is the best place to do so.

I agree most updates don't need a lot of advanced notice. I am particularly concerned about the Project V3 update. The upstream tasks don't have a lot of information about the user experience. The mockups may only partially be implemented by the end of the feature. Phacility states in their documentation that they won't guarantee functionality or experience until they are actively working (or done). Thus i think it would be healthy for a larger set of phacility power users and leads to stay in touch.

I can think of two scenarios where this update may pose a problem. Since they plan to finish the feature by end of year, let's assume changes happen over the next 4 weeks.

• They make incremental but significant changes to boards over the next few weeks. We end up loosing and gaining functionality as we update our extensions. Eventually we get an update that adds their sprints. It's either a breaking change or very confusing. There could also be other unforseen workflow issues which disrupt various teams from time to time.

• They make one large update at some point at the end of the year. There is a lot of functionality that has changed. Our sprint extension is broken.

Both of these would occur around the time we need data for quarterly reviews. It seems like an inopportune time to disrupt our current tools. In general if such a critical tool is changing, we need to surface it, assess its impact and figure out a rollout strategy.

In T120276#1850385, @DStrine wrote:

This is helpful. would you mind providing more information on (how to find these tasks, the boards they live on etc) in the phabricator wiki pages:
https://www.mediawiki.org/wiki/Phabricator

It's all in Phabricator :) (which, honestly, I need to take over ownership of that board and clean up and change Phabricator away from a "team" to a "component", but I'm digressing... there's a lot there I want to clean up, process/board wise... time...)

I agree most updates don't need a lot of advanced notice. I am particularly concerned about the Project V3 update.
[snip... stuff about what could break and why...]
Both of these would occur around the time we need data for quarterly reviews. It seems like an inopportune time to disrupt our current tools. In general if such a critical tool is changing, we need to surface it, assess its impact and figure out a rollout strategy.

Totally agree. Anything big like that we won't just blindly deploy without reaching out :)

In my perfect world: TPG/someone would be interacting with upstream Phab during the course of the ProjV3 development, providing feedback etc, and would know what we should expect and when (when there's more of a there there, of course). Then, when the time comes to upgrade our install to using that new stuff it'd already be known about by the ones who are the experts (TPG) and what we (RelEng) would need to do (if anything) to fix it up locally before deploying.

@DStrine: I monitor https://secure.phabricator.com/w/changelog/ on a regular basis and I monitor the phabricator upgrade tracking task (currently T120013, but you can always find the current one on the phabricator's calendar.

The process is to add blocker tasks to T120013: Next Phabricator Upgrade - 2016-02-18 when there is a fix upstream that we need to merge. Then on the following wednesday I will pull the code, test it, and deploy it. If there are no tasks added there then I will only upgrade phabricator when I see something in the changelog that is particularly useful.

I don't currently plan to do any phabricator deployments until after the end of the year because a) there aren't any major outstanding bugs with fixes upstream, and b) there are some changes upstream that potentially affect our security extension and I need to do more extensive testing once that stuff lands upstream.

@greg and @mmodell Thanks for this

When @greg is addressing his changes to the phabricator projects it would help to update mediawiki as well. The calendar @mmoedll linked would be helpful too. A while back I did heavy editing to the help page to orient it to new users. I think it is still lacking information for more experienced users. You have an opportunity to describe how you want to be contacted.

As mentioned in other channels, it would help to have an email group and/or phabricator "team" that contained phabricator admins, power users and those who wish to be in the loop on such communication.

Like I said in the description, let's just keep in touch on this "projects V3". thanks all

In T120276#1850863, @DStrine wrote:

As mentioned in other channels, it would help to have an email group and/or phabricator "team" that contained phabricator admins, power users and those who wish to be in the loop on such communication.

That should be the Phabricator project, but it is restricted right now for hysterical raisins. I'm trying to fix that (T112040: Clarify #Phabricator project confusion). That way, in the future, you get a hold of those people by filing a task with them (like any other team/project).

See also previous discussion here T95186. I think that subprojects have been the "missing link" for cohesive sprint tracking and reporting in Phabricator. My sincere hope is that they finally include everything that is in the Sprint extension.... and it can go away quietly.

At some point in the next couple months, it seems almost inevitable that we will do one of the following:

1. deploy a new upstream phabricator which breaks things significantly and will have to be reverted, or
2. stop deploying upstream phab releases until we figure out how to reconcile our sprint extension with them, or
3. disable the new phab features until we figure out how to reconcile them with our sprint extension.

It would be awesome to avoid option #1, since that would be highly disruptive to users. It seems likely that we have already deployed a phab version which had unfortunate UX side effects (T120247: Regression: Sprint projects now display project board instead of sprint board by default), which has led to many questions and conversations. And that's just a minor effect. It seems like having some dedicated place for the conversations around a clean transition would be helpful.

This task (T120276: Let's all stay in the loop on the Projects V3 update) was created as an attempt to provide that conversation space. But it seems like a very weird solution to me, because in my mind (which is open to change), a phab task should represent a chunk of work which can be completed. At best, this task currently seems to be a "tracking task", which are discouraged in our phab policies: https://www.mediawiki.org/wiki/Phabricator/Help#.22Tracking.22_tasks

Perhaps we should create a "Deploy phabricator with Projects V3 support" task. It could have blocking tasks such as testing compatibility with our sprint extension, updating our sprint extension to be compatible, configuring phab initially to not use v3 sprints because they would conflict with our sprint extension, setting up a phab staging instance, etc.

Other alternatives would be to move this discussion to a mailing list (which was already vetoed), or to a wiki page (which I would be happy to set up, if I knew where to put it and what to call it).

First my on-topic point:

In T120276#1860710, @ksmith wrote:

Perhaps we should create a "Deploy phabricator with Projects V3 support" task. It could have blocking tasks such as testing compatibility with our sprint extension, updating our sprint extension to be compatible, configuring phab initially to not use v3 sprints because they would conflict with our sprint extension, setting up a phab staging instance, etc.

This seems reasonable. Good idea. We can start out with a single task with some blockers for now and if it grows to be more complex create a project if needed.

I just created T120772: Upgrade to "Projects V3".

Now the off-topic things:

In T120276#1860710, @ksmith wrote:

At some point in the next couple months, it seems almost inevitable that we will do one of the following:

1. deploy a new upstream phabricator which breaks things significantly and will have to be reverted, or
2. stop deploying upstream phab releases until we figure out how to reconcile our sprint extension with them, or
3. disable the new phab features until we figure out how to reconcile them with our sprint extension.

This seems overly pessimistic. Another very reasonable option would be:

1. WMF TPG and RelEng participate actively with upstream on the creation of Projects V3 and when we upgrade we are prepared (sprint extension updated because we've been testing with test installs with the new features enabled, etc, the things you listed above).

Other alternatives would be to move this discussion to a mailing list (which was already vetoed)

No, the idea of a private email loop was tried and (I) vetoed. No public mailing list was included. We can of course continue the discussion of what is happening (with real examples and actual feedback to upstream) on eg the public teampractices@ list.

@greg: Thanks for creating the new task, and for the clarification about the veto.

I hope your optimism turns out to be correct. As an early step, it seems like we should set up a staging area quickly (like within the next couple weeks), in case they move quickly.

I don't expect us to be able to steer phacility's development much, so I suspect mostly it will be on us to react to whatever they choose to do. My best guess of an optimal outcome would be that we could write (and heavily test) some kind of migration script, in order to avoid making any changes to our sprint extension before retiring it. But there are several other possible paths forward, depending on how much like our sprint extension their solution ends up being.

In T120276#1860893, @ksmith wrote:

I don't expect us to be able to steer phacility's development much

I still find this to be selling yourselves/ourselves short. Evan and team are really open to working with people who care about things from everything I've witnessed. They love real use cases and feedback on their work. Sure, they demand high quality contributions (as they should) but that's a bar (I hope) we can meet. I'd prefer to not work with a fatalist view of the world on this.

The latest upstream changes are nearing a point of usability and I have deployed them to https://phab-01.wmflabs.org, please try it out and we can begin figuring out what may potentially break.

Can you please reference what exactly you have deployed? I really have no idea what you are testing against and what your expectations are for my contribution.

What does the "latest upstream changes" mean and how does your understanding of an "early Projects V3 prototype" relate to specific upstream tasks in progress?

For me, the critical upstream tasks are https://secure.phabricator.com/T5100 and https://secure.phabricator.com/T3670 which I am quite sure will break Sprint. The tracking task for these changes is here: https://secure.phabricator.com/T10010 which is now blocked by https://secure.phabricator.com/T10054

See also https://secure.phabricator.com/phame/post/view/754/development_notes_2015_week_52/

@mmodell

As of the writing of this comment, the sprint changes in: https://phab-01.wmflabs.org/ are difficult to assess and seems pretty broken. Does this instance contain our sprint extension as well as the Phacility version?

I created a sprint with what I think is phacility's version:
https://phab-01.wmflabs.org/project/view/38/

I can't assign tasks to anyone or add story points. Also some links to the sprint are broken. When will this be more stable/testable? I would have too many bugs to describe here in detail at this point.

@DStrine: there is no phacility version of sprints. They are called milestones and currently incomplete. I'm going to update phab-01 with newer upstream code and we can try again. I will also try to fix permissions, I think your ability to assign tasks might be related to settings/permissions on phab-01.

I just pulled the latest and took a closer look at what is happening with Subprojects and Milestones. First of all, the new UI features are hidden in the icon navigation bar unless show-prototypes is enabled, but this is the only functional "lockdown" on their use. Both a subproject and a milestone are still "project" objects. The only difference between a subproject and a milestone is that a milestone cannot contain another project object. And, I would say that they have done nothing more with milestone functionality other than implementing a basic UI container for them.

It seems that they are still a long way from recreating the functionality of the sprint extension, unfortunately. Also, the sprint extension still works despite these new changes, because they are adding new controllers rather than changing existing ones. In theory, as long as they do not remove or change any existing project/board functionality, things will continue to work. I have added the paths to these new controllers in the sprint context in this patch https://gerrit.wikimedia.org/r/#/c/263589/1

I do see an obvious path forward for the Sprint extension which would be to fork the milestone UI as the container for sprints and then follow along Phabricator's project model. This would simply allow sprint enabled projects to be better organized. I have to again reiterate, however, that the continued development of the Sprint extension is not sustainable from my perspective.

@Christopher: I agree that it's not long-term sustainable. I think the WMF should wean it's self from whatever sprint functionality we are becoming dependent on, and plan to use milestones which I expect to eventually get fleshed out with more functionality (But this may take some time, obviously.)

Thanks for taking a look.

Is there anything actionable in this task which is not already covered by T120772? Or is this blocked on T120772?
I wonder what this very task is specifically for and what's actionable here. ("Staying in the loop" sounds like some ongoing awareness thingy.)

This task is mostly superseded by Z308. I encouraged @DStrine to create tasks for tracking upcoming issues in Phab deploys (versus email threads) so really it's my fault :).

I say any specific actionables should be tasks in themselves and any discussion about "so, hey, look at this new feature/change" should go in Z308.

Anyone else feel differently?

/me agrees with @greg

Z308 is really helpful. I think we can resolve this task.