[almighty] Project Writeup

Mon Oct 31 14:08:40 UTC 2016

+1 -- it is a large topic.

Note that the external view of Work Item Type Definitions is that it
includes:

1. The fields + data types
2. The permissions (who can edit a field, who can make certain state
transitions, etc.)
3. The workflow
4. The layout of the edit/display form

In fact, each one of those is probably a large topic onto itself.

Also note that for PTH, the only users who have the permissions to
create/change WITDs will be those with operational access to the running
system. (e.g., essentially no end users will have this ability).

On Mon, Oct 31, 2016 at 9:24 AM, Leonard Dimaggio <ldimaggi at redhat.com>
wrote:

> Project workflow (aka state definitions and transitions) is probably a
> large enough topic to require a separate discussion. Will we support a
> basic set of state transitions OOTB, and allow users to create their own
> custom transitions ala JIRA?
>
> Thx!,
> 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/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
>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161031/61caa55f/attachment.htm>