[almighty] Project Writeup

[Thomas Mäder]

Hi folks, I've tried to write up what I think project features are going 
to be in almighty in the future. I've tried to enumerate things that 
seem relevant to how we implement projects in the short run. Once again, 
I would invite interested parties to read through this and point out 
where my understanding is wrong or not complete. Next step would be to 
define what we need to do next to introduce projects.

thx,

/Thomas


  Project functions

Based on the PDD and 
https://github.com/almighty/almighty-core/issues/357, I see the 
following roles for projects in almighty:

  * Process Configuration
    1603E130 & 1603E131 imply that for each project, there is a
    configuration of allowed work item types. I would also expect
    process workflow (states, transitions, permissions) to be configured
    at this level. This requires a way to specify the configuration when
    creating a project. The PDD sees the creation of new configurations
    as a admin level task available to the operators of the service, not
    something that users of the service can do. For the user, it would
    be as simple as selecting a "project type" when creating a project.
    We would have to create a configuration and migrate our existing
    work items into that project.
  * Work Item Owner
    This implies that a work item is a all times associated with exactly
    one project. Deleting the project would imply that the work item is
    deleted as well. It is not clear whether moving a work item would be
    allowed. However, the target project of a move might not allow the
    work item type of the moved work items, so at least we can say that
    it is not always possible.
  * Partition
    Since we expect to have a very large number of work items and links
    between them, we might have to partition the system in some way for
    performance reasons. Keeping work items and links local to a project
    would bring down the number of expected instances to a couple of
    100k. Naively, this would prevent us from doing work item links
    across project boundaries and global searches (what are all the work
    items being blocked by this one? What are all bugs filed by Max
    Andersen?). However, we could replicate information of cross-item
    links in both projects. We could treat searches across projects as a
    special case and offload it to a near-realtime indexing service
    ("Google for mighti").
  * Permissions
    Projects are the object of permissions, meaning that permissions are
    expressed in terms of projects: "Thomas is allowed to create issues
    in Project 'ALM Core'".
  * Team(s) container
    One or more teams will be associated with the project. This is not
    only a permission issue: one might use this for communication (team
    chat) or to determine who a work item can be assigned to. At the
    same time groups of users are traditionally what permissions are
    granted for. If we have general notion of "groups of users", it
    would make sense to associate multiple "teams" with a project:
    administrators, contributors, "guests", etc. These groups would be
    created with the project and assigned a default set of permissions.


  Other topics

  * Nested projects
    https://github.com/almighty/almighty-core/issues/357 introduces the
    notion of nested projects ("projects owning projects"). I am not
    sure where in the PDD this is mandated. It would introduce
    complexity with permissions and process configuration (unless they
    are a restricted form of project). Unless necessary, I would not
    introduce this concept


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161031/a4d3e161/attachment.htm>