Create Spaces [16]

[michaelkleinhenz]

Description

As a user, I want to create projects from the system. A project is a higher context for work items and other data in the system. A work item always "belongs" to exactly one project and all data in the system is always displayed in the context of a specific project. Projects are "owners" of work items and work item links.

Functional Acceptance Criteria

1. The user can create a project from the "create project" view.
2. Creating a project requires a name (alphanumeric value).
3. It is not possible to create a project with an empty name.
4. Projects are working in a way that users in the system are global and can be associated with more than one project (will be a later story).
5. Projects are working in a way that cross-linking of work items between projects is possible (will be a later story).

Note: as mentioned above, users are "global" to the system and can be "member" of more that one project at the same time. This is not a direct functional requirement, but a hint for design decisions.

Note: projects are "owners" of work items and work item links. Work items and projects should be designed that cross-linking of work items between projects are possible later. TBD is the ownership of the work item link instance on cross-linked work items. This is not a direct functional requirement, but a hint for design decisions.

Note: on the scope of this story: as part this story, we will extend our object model by introducing a 1:n relationship between the newly created "project" and work items. On the back end, we will have to introduce a CRU(D) service for projects and extend work item creation with a mandatory "project" parameter. How that parameter is passed and stored needs to be discussed as part of implementation.
The front end needs to add UI to create a new project and introduce the notion of a "selected" project that is passed when creating a work item. As part of migration, we will have to create a default project and assign all existing issues to that project.
Out of scope (explicitly not addressed by this user story): authorization, orgs, teams, areas, configuration of process for a project (WI types, etc.) and moving work items between projects.

Non-functional Acceptance Criteria

1. The "create project" view is easily accessible from anywhere in the system UI.
2. Creating a project adds the new project in-place to the project selector.
3. The result of the implementation of this story should also be a basic data model and a concept for organizing projects and other entities.

Dependent Stories

1. Userstory View/Selecting the active Space [13] #358

Tasks

• Create Repository for project crud(l) Create Repository for Project CRUDL #509
• Create API Endpoint for project crudl Create API Endpoint for Project CRUDL #510
• Update work item create/update to include optional "project field" if empty, assign to a default project
  *migrate all existing work items to default project Update Work Item API to include Project #511
• Update search services (wi list and @searchrepo) to allow filtering by project Filter by Project in WI Search Services #512
• Make project field in work item create/update mandatory
  • this can be done once the front end is ready to pass a project with work item create/update (View/Selecting the active Space [13] #358)

[michaelkleinhenz]

Start of discussion: about the nature of a project: what are the boundaries? Do users are per-project or per-installation? Are all WIs always per-project? Can there be WIs that are cross-project? Do all these matter in the context of the short-term goal? @aslakknutsen @maxandersen

[maxandersen]

WI's are imo part of one project but other projects can include a WI in their value props, epics, etc.

[ldimaggi]

Will we support users moving work items between projects ala JIRA?

[VineetReynolds]

@michaelkleinhenz A few comments for the questions you've raised:

cc @maxandersen @aslakknutsen

Do users are per-project or per-installation?

I see projects as a namespace to hold a team, i.e. every project in the system has a set of users who work on it. The same human user behind the project should be registered by the system only once (for instance, sign up at developers.redhat.com). But at the same time, the user would have different (or even no roles) in different projects in the system, so users may need to be onboarded to be a member of a project team. Users should not be required to sign up multiple times into various project instances.

So, imho, every project has a team that is used to link projects with various registered users in the system.

This would tie somewhat into the permissions model, as you may need unregistered users to perform certain operations, like commenting on WIs. All such concerns could be extracted out to separate stories.

Are all WIs always per-project? Can there be WIs that are cross-project?

I'd see projects as owners of WIs, i.e. the project namespace should contain the WIs in that project. WIs could be linked from one project to another, with different link types (duplicated by, depends on, related to etc).

From a functional perspective, projects have WIs, and WIs have links to other WIs in the same or different projects. I believe #322 and #323 do not deviate from my understanding of WI links.

I sense there is a technical concern here on how you want to store the links and manage them, so I won't comment much at the risk of misguiding the team on technical aspects, but I can take those questions if needed.

Again, feel free to split the overall story on WI links.

[nimishamukherjee]

@michaelkleinhenz :
@joshuawilson had shared this from the Westford meeting. We could refer to it while working on Projects.

[michaelkleinhenz]

@nimishamukherjee ah, I now understand the concerns about the Area/Category. For this topic, I think the PDD reads that Area (in the above image) and category are different things. Categories are like components in Jira, Areas are the hierachy of the project structure.
On the users: the diagram suggests that users are local to the project. For many reasons and also @VineetReynolds remarks I would consider users in the diagram differently from "accounts" in the system, which should be global.

[michaelkleinhenz]

@ALL updated the story with the new info.

[maxandersen]

@michaelkleinhenz I would argue components are a "weaker" form of what area is. the main difference between area and components are that components are a "flat" hierarchy but then instead one issue can be in multiple components. Question is if we want to have the strict hiearchy or allowing for mulitple areas is relevant.

[maxandersen]

one thing to remember here is that Projects are intended to cover more than just planner WorkItems - projects is also what should show up in webide, builds, etc.

[RanjithRV]

I am guessing the length of the Sprint (Time-box) and/or Release be defined at the Project level? Shouldn't that be part of the acceptance criteria? Since we are sticking with Scrum version of Agile for the Summit deliverable, should that be the default option at the project level for now?

[michaelkleinhenz]

@maxandersen on the components: yes, thats also my impression. And like for the projects, I would go for a flat model first and add hierarchy later. I'll add that to the categories story.

[michaelkleinhenz]

@maxandersen on the projects: yes, I'd think projects are the "functional root" of other data.

[michaelkleinhenz]

@RanjithRV I would put the time configuration in the iteration to allow flexibilty on the timebox per sprint (like, we need 2 days more because of holidays). The iteration stuff is not yet written down in stories, but I am on it :-)
But yes, at some point, the project does need more metadata, maybe also a "default iteration length". I would add that in a later story when we do the iterations.

[maxandersen]

@RanjithRV I think the length of sprint is defined on the sprint/iteration itself not on the project.
the sprint/iteration i think makes sense to have within one project.

But one could argue that you could have multiple projects follow the same sprint model (think devtools), and I even think in jira sprints live outside projects, allowing multiple projects and boards to collabroate on sprint planning.

[ldimaggi]

This issue refers to projects as: "Projects are "owners" of work items and work item links."

Does "container" make more sense as a description for a project? Isn't a project just a title and a groups of links to work items, users, other projects, etc.? Thx!

[tsmaeder]

In scope

As part this story, we will extend our object model by introducing a 1:n relationship between the newly created "project" and work items. On the back end, we will have to introduce a cru(d) service for projects and extend work item creation with a mandatory "project" parameter. How that parameter is passed and stored needs to be discussed as part of implementation.
The front end needs to add UI to create a new project and introduce the notion of a "selected" project that is passed when creating a work item.
As part of migration, we will have to create a default project and assign all existing issues to that project.

Out of scope

The following things will explicitly not be addressed by this user story:

• authorization
• teams
• areas
• configuration of process for a project (wi types, etc.)
• moving work items between projects.

Further evolution

In our current linking story, links are not associated with a project, and thus cross-project links are trivially possible. If we chose to partition the system along project boundaries in the future, we'll need to split existing links. Having one project be the owner of a cross-project link does not make sense for symmetric relationships (related-to, etc.)
I believe what Michael means by "nested projects" are what the PDD calls "areas". Introducing them later would entail migrating existing issues to a newly created "default area" per project.

[Mgranfie]

Thanks Thomas. This seems reasonable. Just checking that you can move a WI
between an iteration within a project? Is that on the table?

On Tue, Nov 1, 2016 at 5:52 AM, Thomas Mäder notifications@github.com
wrote:

In scope

As part this story, we will extend our object model by introducing a 1:n
relationship between the newly created "project" and work items. On the
back end, we will have to introduce a cru(d) service for projects and
extend work item creation with a mandatory "project" parameter. How that
parameter is passed and stored needs to be discussed as part of
implementation.
The front end needs to add UI to create a new project and introduce the
notion of a "selected" project that is passed when creating a work item.
As part of migration, we will have to create a default project and assign
all existing issues to that project.
Out of scope

The following things will explicitly not be addressed by this user story:

• authorization
• teams
• areas
• configuration of process for a project (wi types, etc.)
• moving work items between projects.

Further evolution

In our current linking story, links are not associated with a project, and
thus cross-project links are trivially possible. If we chose to partition
the system along project boundaries in the future, we'll need to split
existing links. Having one project be the owner of a cross-project link
does not make sense for symmetric relationships (related-to, etc.)
I believe what Michael means by "nested projects" are what the PDD calls
"areas". Introducing them later would entail migrating existing issues to a
newly created "default area" per project.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#357 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARTwq-DQYVWxyl7x5kXtIBcmz-PhNR4sks5q5wvigaJpZM4KVAgC
.

[ldimaggi]

Question on this statement:
'...The front end needs to add UI to create a new project and introduce the notion of a "selected" project that is passed when creating a work item...'

Will a user always be working in the context of a "current" project? Or, will the user have the option of selecting a project when creating a new work item?

[tsmaeder]

@Mgranfie For me, it's not part of this userstory

[tsmaeder]

@ldimaggi I did not find any info on that. I guess it's a decision for UX to make.

[VineetReynolds]

@Mgranfie wrt

Just checking that you can move a WI
between an iteration within a project? Is that on the table?"

This would be under the sprint/iteration planning stories. Short answer - I'd expect WIs to be moved between iterations.

[michaelkleinhenz]

@Mgranfie yes, WIs can be moved between iterations. See #412 for that.

[tsmaeder]

Backend Tasks:

• Create Repository for project crud(l) Create Repository for Project CRUDL #509
• Create API Endpoint for project crudl Create API Endpoint for Project CRUDL #510
• Update work item create/update to include optional "project field" if empty, assign to a default project
  • migrate all existing work items to default project
    Update Work Item API to include Project #511
• Update search services (wi list and @searchrepo) to allow filtering by project Filter by Project in WI Search Services #512
• Make project field in work item create/update mandatory
  • this can be done once the front end is ready to pass a project with work item create/update (View/Selecting the active Space [13] #358)

[tsmaeder]

Front end tasks:

• "Create Project" dialog
• An affordance to invoke the "create project dialog" (menu entry, for example)

[tsmaeder]

Switzerland: 20 points.

[baijum]

13 Points

[hectorj2f]

We're now able to create projects==spaces. Closing this issue!