[almighty] Project Writeup

[Todd Mancini]

Another big topic; worthy of it's own thread. :)

On Mon, Oct 31, 2016 at 9:30 AM, Monica Granfield <mgranfie at redhat.com>
wrote:

> I am not sure we are including roles, although I would think they are
> useful, as they are basically pre-packaged/template permissions for reuse.
>
> On Mon, Oct 31, 2016 at 9:25 AM, Leonard Dimaggio <ldimaggi at redhat.com>
> wrote:
>
>> P.S. wrt to teams - are we thinking about defining roles for users -
>> where each role definition consists of permissions to perform specific
>> tasks?
>>
>> --Len D.
>>
>> On Mon, Oct 31, 2016 at 9:18 AM, Thomas Mäder <tmader at redhat.com> wrote:
>>
>>> 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/al
>>> mighty-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
>>>
>>>
>>>
>>> _______________________________________________
>>> almighty-public mailing list
>>> almighty-public at redhat.com
>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>
>>>
>>
>>
>> --
>> Len DiMaggio (ldimaggi at redhat.com)
>> JBoss by Red Hat
>> 314 Littleton Road
>> Westford, MA 01886  USA
>> tel:  978.392.3179
>> cell: 781.472.9912
>> http://www.redhat.com
>> http://community.jboss.org/people/ldimaggio
>>
>>
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161031/8dac7fc7/attachment.htm>