Page MenuHomePhabricator

Create a document describing possible Phabricator practices
Closed, ResolvedPublic

Description

As part of the work to invent processes for the API and Search teams, start to document specific ways to use Phabricator:

  • Creating projects (team, sub-projects, sprints, milestones, categories)
  • Workboard columns
  • Estimation, story points,

Event Timeline

ksmith claimed this task.
ksmith raised the priority of this task from to Needs Triage.
ksmith updated the task description. (Show Details)
ksmith subscribed.

As I pointed out on IRC, documentation exists on mw:Phabricator/Help, mw:Phabricator/Project management, mw:Phabricator/Creating and renaming projects and should be potentially extended (sections, subpages) to avoid duplication.

@Aklapper: Yes, the end result will be changes to that document. I'm going to start working in a sandbox, and then figure out how to combine the results. Some of this document may include guidance that the Team Practices Group agrees to advocate for, but which might not qualify as universal best practice advice. Any recommendations for how to deal with that kind of material?

Any recommendations for how to deal with that kind of material?

Not really, apart from being bold - if cases to cover get too many or specific, linking to subpages on the wiki might be useful.

All thoughts (or edits) would be welcome, but if you can't look at anything else, please focus on the work boards section. I'm especially interested to know how well it aligns with what is actually being used by teams today.

When you're done, please assign to Kristen for her similar review.

ggellerman set Security to None.
ggellerman added a subscriber: JAufrecht.

Very helpful - I would definitely think everybody should read this before going into Phab.

Putting questions here - they could go to a new Task if answer warrant it:

  1. "Sprint Workboards would almost always be configured to represent Workflow." What else would a Sprint Workboard be used for?
  1. "The Task gets reassigned to whoever needs to work on it next". Is "The Task gets assigned to its original filer to consider resolution?" a third pattern, or just a subcase of the second pattern?
  1. So there's no relationship between the status field and the "status" columns? Or, put another way, you can create any arbitrary set of statuses you want, one set per Project, and also all tasks have meta-status of Open or Resolved (and Stalled)?

@JAufrecht Thanks for the great feedback. I have addressed all three of your suggestions in the page.

To answer your last question, that is mostly correct. The status (which is limited to one of the 5 defined values) has no technical relationship to implied states based on what column(s) the task is in in various workboards.

Is there a followup task I can subscribe to that covers "Integrate this sandbox with existing documentation"?
As written before I'm still afraid enough of duplicated documentation (even if just in the long run).

(Plus not sure if "Merged/Duplicate" should be covered as a status. At least in the existing docs I did.)

@Aklapper The follow-up task is T98521. And I agree with you that this does need to get merged in. My current hope is that I might have time to work on that in June. My other hope is that there isn't actually much duplication between the tips page and the other pages, although I realize there is some.

I will contact you separately with questions about Merged/Duplicate.

@Aklapper The follow-up task is T98521.

Ah, thank you!
(For future reference, just mentioning the ID in the description of T98521 (e.g. "This is followup work for T94484") would have triggered a notification in T94484.)