qgil wrote on 2014-04-22 18:03:22 (UTC)

It looks like Phabricator provides enough elements for us to define this process.

aklapper wrote on 2014-04-24 09:15:47 (UTC)

Projects + queries (like "open tickets in all these projects: '1.23.0 release' && 'MediaWiki'").

qgil wrote on 2014-04-24 14:05:29 (UTC)

There is a plan to implement project types that would include

( ) Tag
  Tags are lightweight projects that don't have members or wiki pages.
  
( ) Sprint
  Sprint projects organize work into a series of iterations. Iterations
  are created automatically and incomplete tasks roll from one iteration to
  the next.

In the meantime, I think we could work with specific projects and queries. According to some comments in that task, this is how some orgs are doing it.

qgil wrote on 2014-04-28 13:14:48 (UTC)

Moving here this comment from @Awjrichards at T44: Migrate Bugzilla attachments to Phabricator

• The concept of bucketing 'tasks' into an 'iteration'
  • This also includes the ability to look at past iterations (and what was contained in them)
  • As well as the ability to look at future iterations (and what will be contained in them)
• The concept of bucketing 'iterations' into a broader 'release'

mattflaschen wrote on 2014-04-29 04:30:12 (UTC)

(Due to http://fab.wmflabs.org/T164 we can't have two levels of dependency so I suppose we'll instead give up on granularity.)

Do you mean that you can't visualize two levels in a chart? You can have arbitrary dependencies, as far as I can tell. Two-level example: T248 depends on T249, which depends on T250.

qgil wrote on 2014-05-15 14:07:55 (UTC)

At the teampractices mailing list there is a discussion about how to organize sprints. While the upstream solution arrives, it would be good to know how Phabricator users do this nowadays.

As far as I can see, the process seems to be something like this:

1. A Project X exists containing several tasks. Optionally, a team is created for it.
2. A new Project X Sprint 1 project is created. The tasks from Project X to be included in the sprint are tagged accordingly. The only relation between these projects is their naming convention. For Phabricator these are independent projects. Herald rules can be created to assign to Project X any task created for Project X* automatically.
3. At the end of the sprint, Project X Sprint 1 is archived and Project X Sprint 2 is created. The remaining tasks of Sprint 1 can be moved to the next sprint with a single batch edit.

There are some manual steps that in the future should be automatized, but other than that the process seems to be simple enough? Creating projects is simple, you only need to add a title and, if you wish, you can copy & paste a stock description. Membership of these subprojects is not relevant. If you want to set some special permissions for the developer team you can simply set those permissions to the Project X team.

aklapper wrote on 2014-05-30 15:16:16 (UTC)

Copying @jdforrester's comment from T167:

We'd discussed creating a project for each deployment – so "WMF server deployment 2014-05-29 (1.24wmf7)" etc.. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.

If we did that, we might want to be able to close projects if they are in the past (disable adding a project to a task). Now I need to find out if that's possible already, and if not I'll upstream.

The problem I see is that we'd want to add such a "Deployment Target Milestone" project to tasks automatically in the long run: Closing a task in a certain timeframe in a certain project should automatically add this project to the task. Which will be a complex feature request.

aklapper wrote on 2014-05-30 15:39:17 (UTC)

Answering my own question thanks to upstream IRC:

we might want to be able to close projects if they are in the past (disable adding a project to a task).

<mikkn> If you go to Projects then click on the project in question, then edit, you will have an "Archive Project" button there

jdforrester wrote on 2014-05-30 15:53:56 (UTC)

In T166#33, @Aklapper wrote:

Copying @jdforrester's comment from T167:

We'd discussed creating a project for each deployment – so "WMF server deployment 2014-05-29 (1.24wmf7)" etc.. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.

If we did that, we might want to be able to close projects if they are in the past (disable adding a project to a task). Now I need to find out if that's possible already, and if not I'll upstream.

The problem I see is that we'd want to add such a "Deployment Target Milestone" project to tasks automatically in the long run: Closing a task in a certain timeframe in a certain project should automatically add this project to the task. Which will be a complex feature request.

That'd be a nice-to-have, but we don't have it on Bugzilla and I manage it manually instead. The important thing would be an automtic "add change to project", which presumably we could do as part of the script that currently posts the list on MediaWiki.org?

qgil wrote on 2014-05-30 19:19:49 (UTC)

Maybe this sounds silly, but what about

1. Work on the tasks at project "WMF server deployment 2014-05-29 (1.24wmf7)".
2. By the end of 2014-05-29, some tasks will be resolved and forgotten, others will remain open.
3. Rename the project to "WMF server deployment 2014-06-05 (1.24wmf8)".
4. Add the new tasks you want to complete in addition to the ones you still have open.

If you don't like the idea of simply renaming projects for whatever obscure archiving reason, then "Edit batch" selecting ll open tasks of a project can make wonders. Not automatic but still pretty simple.

jdforrester wrote on 2014-05-30 21:35:40 (UTC)

In T166#37, @Qgil wrote:

Maybe this sounds silly, but what about

1. Work on the tasks at project "WMF server deployment 2014-05-29 (1.24wmf7)".
2. By the end of 2014-05-29, some tasks will be resolved and forgotten, others will remain open.
3. Rename the project to "WMF server deployment 2014-06-05 (1.24wmf8)".
4. Add the new tasks you want to complete in addition to the ones you still have open.

If you don't like the idea of simply renaming projects for whatever obscure archiving reason, then "Edit batch" selecting ll open tasks of a project can make wonders. Not automatic but still pretty simple.

Where would the static links to "tasks fixed in <sprint/deployment>" and "code landed in <sprint/deployment>" live? That's one of the key needs from my POV.

qgil wrote on 2014-05-30 21:40:04 (UTC)

In this case, renaming projects is not an option.

Wouldn't the workboard of <sprint/deployment> be enough?

aklapper wrote on 2014-06-06 17:14:12 (UTC)

Spent the afternoon thinking about this item. Please show me that I'm wrong and that this can be made less complex.

Underlying assumptions:

• On branching for a new xx in WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd): No fix for a task / commit can be included in WMF server deployment 1.xx-wmfZZ which would not also automatically be included in tarball 1.xx-rc or tarball 1.xx.0. In other words: When switching from WMF server deployment 1.23-wmf26 to WMF server deployment 1.24-wmf0, the tarball branch for 1.23 gets created at the very same time.
• The term ''version'' in the rest of this comment refers to a string like 1.xx.y or 1.xx-wmfZZ or Sprint 1 or yyyy-mm-dd. It might also be an iteration or a sprint (simplified as several iterations can become a release / version, but I really got to start somewhere).
• We do not rename projects which include versioning in their names as it would make ChangeLog creation (and burndown charts?) impossible. Discussed above in T166.

Situations we face:

• Planning to fix a task in a future version (WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd), would automatically also end up in tarball 1.xx.0)
• Planning to fix a task in a past version (backporting to servers; only applies for WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd))
• Documenting that a task got resolved in a timeframe (cf. ChangeLog), hence fixed in WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd), would automatically also end up in tarball 1.xx.0. (TODO: No idea if this could be set automatically, but that would be lovely.)
• Documenting that a task planned for a version (well, rather explicitly sprint in this case) was planned but did not get resolved in that timeframe.

Conflict about interpreting versions (affected vs fixed in):

• If we reflect versions in or via project names, we easily end up with a semantic conflict when the task is closed as resolved: Was that version affected by the bug reported in the task? Or did that version include a fix for the bug reported in the task?
• I tend towards using Versions which include a fix for a problem/task because planning is more important in a task management tool than info about the version used by the task's reporter. This must be clearly expressed in our docs (T350).
• Making this clear is also important for projects with sprints / release cycles not aligned with WMF deployment cycles (also keep 3rd party development in mind).

Getting notified about backporting requests (T167):

• Refering to the situation Planning to fix a task in a past version (backporting to servers); the third assumption says We do not rename projects which include versioning in their names.
• In practice it means that when 1.xx-wmfZZ gets deployed on the first WMF servers, Release Management (Greg etc) would have to subscribe via Herald to watch the project WMF server deployment 1.xx-wmfZZ in order to get notifications whenever a task is added to that project (= a request to backport).
• The same thing would happen every 7 days (for WMF server deployment 1.xx-wmfZZ+1, etc.) which sounds really cumbersome and error-prone.
• Instead we might want to have a "static"/"generic" Backport to WMF project so people don't have to subscribe to its notifications every week?
• Once a backport has been granted and merged, the task must be edited by removing the Backport to WMF project and by adding the WMF server deployment 1.xx-wmfZZ project. Disadvantage here: We'd lose statistics on how often we need to backport stuff.
• TODO: We might also have to document that the task whose fix should get backported must remain open (T350), not sure how flexible the notification system is.)

Based on that above assumptions can be considered correct, we might end up with these things in parallel:

• generic projects: MediaWiki (covered in T68; task reporters are encouraged to set them)
• sprint/iteration projects: Team XYZ Sprint 23 (2014-05-08)
• WMF server deployment projects: Fixed in WMF server deployment 1.xx-wmfZZ
• One generic WMF backport request project release management should subscribe to: Backport to WMF servers
• For projects not following the WMF server deployment or MediaWiki tarball release schedule: Fixed in $projectname x.y.z

Tarball release projects (like MediaWiki release 1.xx.y) for fixed/resolved tasks would not be needed if the aforementioned first assumption on branching holds true, as one could query for all tasks in project WMF server deployment 1.xx-wmfZZ where 0 ≤ ZZ ≤ 26.
Though I am not convinced if that would be discoverable enough to 3rd party MediaWiki users in order to find out in which tarball version a fix is supposed to be included - TODO: might need to document that.

So.... does this novel make any sense?

mmodell wrote on 2014-06-09 17:51:24 (UTC)

Documenting when a big fix got released should be simple because you can link a git commit to a task as well as linking differential revisions. It would be trivial to traverse the git log from the newest commit to find the next release tag that occurs between the relevant commit and HEAD. That version tag can be exposed In the task ui as the first release containing the fix.

jdforrester wrote on 2014-06-09 18:16:52 (UTC)

In T166#40, @Aklapper wrote:

• Planning to fix a task in a past version (backporting to servers; only applies for WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd))

Actually, we also do this for releases – tagging bugs as things that need to get fixed in 1.23.1 for example. However, I don't think it makes a major difference.

So.... does this novel make any sense?

Yes! It looks good. I'd suggest having a "Backport to MediaWiki releases" project for the MW release maintainers as well, but yes, it works for us.

aklapper wrote on 2014-07-06 20:35:34 (UTC)

Upstream decided to try subprojects in https://secure.phabricator.com/T3670 (makes our T240 a WONTFIX), which "will make an attack on sprints/milestones/versions." This might make our life easier?

SG wrote on 2014-07-10 20:27:36 (UTC)

That does seem like it would fit our needs. It's slightly less clunky than our proposed solution.

aklapper wrote on 2014-08-10 19:58:22 (UTC)

For the time being (as implementing subprojects might take too long for us in upstream), the basic idea is to use projects (tags) in Phab, differentiating types via icons and colors. For releases ("target milestones" in Bugzilla), imagine a truck tag for example, or check out the preliminary screenshot.

Not entirely set in stone yet and just to show the basic idea. All kudos goes to Chase.
Sigh, as I get an "Upload Failure" both with Chrome and Firefox here, external link to screenshot: http://home.arcor.de/ak-47/tmp/Phab-Project-Tags-T46.png

I got a bit lost with the discussion above and what we will start doing right now. Different tags for project and release, or single tags "project + release"?

Above you have covered stable MediaWiki releases 1.xx and also WMF weekly releases 1.xx-wmfZZ. Could we also add months as in yyyy-mm for those teams organizing monthly sprints? This is the case of at least Engineering Communty, but I imagine we are not the only ones.

PS: enthusiastic thumbs up for !

I just created a project for the Engineering Community October 2014 sprint. A sprint is not a release, so I used another icon:

Sprints could have a color on their own, or they could have the same as releases, not to end up with a full-fledged rainbow.

Different/separate tags for project (e.g. ' VisualEditor') which covers all tasks in a project, vs. release (e.g. ' VisualEditor 1.0.1') and vs. deadline (e.g. ' VisualEditor 2014-12-24').

Trying to keep it simple for the start: Combine one color with one icon.

• Projects have a Briefcase icon (and blue color).
• Releases have a Release icon (and orange color).
• Sprints have a Deadline icon (and some other color - indigo? shrug).
• For completeness: Cross-project 'keywords' (Bugzilla terminology) have a Tag icon (and red color I think).

Target Milestone data migration:

Sorry, this fell through the cracks and this is not entirely 'ready to go' yet but close.

I'm currently checking the use of Target Milestones in Bugzilla products, and which TMs are in the past so I can disable setting these TMs in Bugzilla (cleaning up but need to talk to several teams), and which TMs are rubbish (see e.g. https://bugzilla.wikimedia.org/show_bug.cgi?id=71807 ).

Projects in Bugzilla using Target Milestones:

• Huggle (3 TMs, 3 of them active)
• MediaWiki (15 TMs, 6 of them active)
• MediaWiki extensions (8 TMs, 5 of them active)
• MediaWiki skins (1 TMs, 1 of them active but TM set on 0 tickets)
• VisualEditor (89 TMs, 89 of them active but asked James if past ones could be made inactive)
• Wikimedia (1 active TM called 'Mysterious future' which I want to delete, see https://bugzilla.wikimedia.org/show_bug.cgi?id=71807)
• Wikipedia App (2 TMs, 0 active)

Question: Not sure if that makes things more complicated or not in the migation logic hence question might not make sense: I'm wondering whether we could/should ignore past TMs (TMs that are 'not active' / cannot be set anymore on Bugzilla tasks) and not necessarily migrate them into archived projects in Phabricator. On the other hand we'd lose data, e.g. which VisualEditor bug was fixed at which time, hence probably going for archived makes more sense.

In any case, Bugzilla TMs should become deadline or release projects. See my previous comment.

Happy for the VisualEditor TMs to be magically transformed into projects to which each Bugzilla item is transferred as appropriate, but yes, we really need to keep that data if at all possible.

In T100#9608, @Aklapper wrote:

Trying to keep it simple for the start: Combine one color with one icon.

Deal.

• Projects have a Briefcase icon (and blue color).
• Releases have a Release icon (and orange color).
• Sprints have a Deadline icon (and some other color - indigo? shrug).
• For completeness: Cross-project 'keywords' (Bugzilla terminology) have a Tag icon (and red color I think).

Yes to most points, but look what I've done instead:

M4 Phabricator project labels

30

Let's finish the discussion about icons and colors in the mockup.

Are there any more details that must be decided here? We really need to close this task, or at least have it in a state where it is not blocking T259 anymore.

In other words, the period for input to the migration script needs to end. We can always file tasks based on the results of T552: https://bugzillapreview.wmflabs.org/ migration preview instance.

Thumb ups from me, this fits my team's workflow.

Works for us. I like the rainbow.