Rush wrote on 2014-07-15 18:15:15 (UTC)

made this task more out of practice / as a measure of a possible process. Hopefully is useful to think this way?

MissGayle wrote on 2014-07-15 18:21:49 (UTC)

Well, HR has a bunch of projects.
For instance, we have "Applicant Tracking System Migration & Implementation" as a project we'd like to run publicly. Does that get its own separate project? Is there a way to nest it under HR projects?
Or do the tasks related to that get jumbled in with the other tasks in HR?

Rush wrote on 2014-07-15 18:41:57 (UTC)

The way it works now...

A project name is like a label, tasks can have lots of labels. There are different types of labels as well. Some labels are meant to just link a lot of oddball but related things together from various corners. Some labels are meant to contain list of people. Some labels are meant to function as work queues.

We could do...

hr-applicant-tracking
hr-learn-to-tango

These would both allow tasks to be associated with them, even both labels at once. These would not be found with a 'show me all projects that start with hr' type search. Upstream knows the project organization gets weird as the list gets bigger.

Because projects are super freeform they don't nest well, as in...

hr:
--> learn to tango
--> applicant-tracking

true sub-projects seem to be a pretty heavy effort for the maintainers, and I have seen lots of discussion and work there ongoing.

The way I have done it broadly...

For finite we need to get from a to b with x number of steps create a task and use sub-tasks.

• Task: Build a dancefloor
  • subtasks:
    • buy wood
    • call guy who has hammer

These don't get workboards tho, think trello.

Use long-running projects to separate work queues (we can tag these appropriately)

• hr-new-hire
• hr-benefit-disputes

Use freeform tags to group tasks across work-queues for shorter lived goals:

• onboard-chase

has a task in hr-new-hire and a task in hr-benefit-disputes

synopsis is: projects are cheap but that cheapness is only in terms of appropriation, it gets really confusing if different levels of abstraction are used for the same type of project classification.

Rush wrote on 2014-07-15 18:47:10 (UTC)

I realized this could be overwhelming and confusing.

Best practice, let's make a general humanresources project and then as tasks come to together we can start to break them into more definable sub-groups?

qgil wrote on 2014-07-16 12:04:06 (UTC)

I agree that the best approach is probably to start with a "people" type of project for "Human Resources" (the same label used here, and the one that interested users are more like to find). Then if you see that a bunch of tasks belong to a single HR subproject, you can always request the creation of a new project and add/move the related tasks there. Tasks can belong to several projects, so we have the flexibility to grow organically.

About team members, maybe the best approach is to grant the permissions to add members to the "Human Resources" team (initially @MissGayle alone).

Permissions to edit tasks can be also granted to the "Human Resources" team.

Elena wrote on 2014-07-16 21:07:58 (UTC)

@MissGayle I'm interested in using phabricator to manage some of my upcoming projects. Let me know if it's ready to experiment with on the hr end.

qgil wrote on 2014-07-17 11:56:40 (UTC)

Project created: http://fab.wmflabs.org/project/view/58/

Only the Human Resources members can add/remove project members. @MissGayle has to add new members, and the new members will be able to add other members. I have kept myself as team member just in case; I will remove myself as soon as it is clear that the theory works in practice.

PS: @Elena, I could have added you straight away but I thought it would be more useful to give Gayle a chance to train in her new Phabricator role. :)

MissGayle wrote on 2014-07-23 17:02:04 (UTC)

Quick question, can we have multiple workboards per project?

MissGayle wrote on 2014-07-23 17:10:56 (UTC)

Hmm...

Trying to figure out how to organize this. I don't think in terms of "tasks" then clumped under projects. I think of overall projects with tasks assigned to them, and we have a lot of them that vary in terms of size and scale. Even between Recruiting, Learning & Development, and HR Infrastructure (the three main components of my department) each has specific projects.

qgil wrote on 2014-07-23 17:15:44 (UTC)

In T458#18, @MissGayle wrote:

Quick question, can we have multiple workboards per project?

No, but you can have multiple projects, each with its workboard. Tasks can be assigned to more than one project and, therefore, they can appear in more than one workboard.

Trying to figure out how to organize this. I don't think in terms of "tasks" then clumped under projects. I think of overall projects with tasks assigned to them, and we have a lot of them that vary in terms of size and scale. Even between Recruiting, Learning & Development, and HR Infrastructure (the three main components of my department) each has specific projects.

Fine, why don't you define a first project, fill it with tasks, start playing with the board... Then a second. Then a third. The you're on a roll!

importing issue status

@Pine: Is there a reason why the Phabricator project WMF-Human-Resources at https://phabricator.wikimedia.org/project/profile/22/ has an Edit Policy restricted to "Allow users: @GYoung, @Pine"?

Also, there is no description set what that project is about. And hence I have no idea when associating tasks is appropriate or not.

@Aklapper yes, Gayle requested that I restrict that project. My understanding is that WMF rarely uses that project, and that HR does almost all of its work privately, probably in Asana which Finance also uses (and I think that Community Resources uses as well). So, essentially, that project is mostly a placeholder in case HR eventually moves at least some of its work to Phabricator. Interestingly, it seems that WMF's technical security people do use Phabricator for their private work, so perhaps HR, CR and Finance will move to Phabricator eventually, perhaps with some public and some private work in separate projects.

Restricting project editing to specific users only should probably never be allowed.

This is already done on other projects; I believe that Learning and Evaluation and the Community Liaisons also have some projects set up this way. If you'd like to have a broader discussion about when restricting project editing to certain users should or shouldn't be allowed, I suggest opening up a new task for that, and/or discussing with Quim and/or Terry.

I think this is just the result of a misunderstanding that was frequent back in last Autumn (that restricting policies of projects would restrict the policies of the tasks associated to those projects). The HR project can and should have the default policy, since it is not granting permissions for anything. If the HR team is interested in using Phabricator for restricted tasks, we can talk about that in a new, separate discussion.

And in all fairness, WMF HR never asked to have a project created here. They just found the one created by Pine very early on.

@Qgil no, please see discussion above. I didn't create the HR project. However, I did lock down the one that existed at Gayle's request. Since Gayle is no longer with us and I'm just mainly guarding that project to prevent misuse, I'm happy to re-open it if there's a request from HR. It sounds like you think this is a good idea, so I'll run this by Joady.

I would just like to say from an ops point of view it would be AMAZING if we could work with you guys on Phabricator for the onboarding and offboarding workflow. (--> T108131)

@Dzahn I've added that task to HR at your request. Even with the project description locked, anyone can add tasks to the project.

Joady has informed me that HR is currently using Asana exclusively, so I'm in the process of locking down the Human-Resources project as best as possible while keeping intact the information that's currently there.

@Pine, sorry for the misunderstanding. So many tasks have rained since those days and my memory failed (and I didn't check logs).

The right course of action here is to set the policies of this project to default and archive the project as a simple, not useful label. @Pine, please unprotect it and archive it. Thank you.

I will go through the open tasks associated with it now.

In T284#1537065, @Pine wrote:

@Aklapper yes, Gayle requested that I restrict that project.

I'm afraid that 'restrict that project' had a very different intention in mind than what was actually technically done in Phabricator. Project membership was restricted, but that does not restrict any access to any of the project tasks, so effectively it's pretty useless IMHO.

In T284#1538730, @Qgil wrote:

@Pine, please unprotect it and archive it.

+1. Thanks in advance.

I will go through the open tasks associated with it now.

Thanks!

Project membership wasn't restricted at the time; what was restricted was editing the project details.

Per discussions, I have archived the project.

I've added Phabricator administrators to the list of people who can edit the project. Is there a reason to allow *anyone* to edit the project details of this archived project? It makes sense to allow administrators to un-archive the project, but I don't think it's necessary to let just anyone edit it.

In T284#1547257, @Pine wrote:

Is there a reason to allow *anyone* to edit the project details of this archived project?

Yes, we don't protect things unless protection is actually necessary.

Ok, since the default is the Wikipedia-like "anyone can edit", I'll update that setting momentarily.