References

If this reference is not set then EObjectActionProvider creates a new Action using AppFactory in newAction() method. If this reference is set and is Action then a copy of the action is created and returned. Otherwise the reference value it is adapted to ActionProvider which is used to create an action. This allows to merge actions and chain action generation. E.g. generate Ecore model documentation and merge it into the Engineering documentation.

Engineers managed by this engineer.

Issues (work items) for this element.

Allocations of engineer’s capacity to work on this engineered element issues for a particular endeavor and issue category.

Map entries

Sub-forums.

Element documentation, e.g. Markdown documentation.

Period end.

Experts have expertise with the element, but no authority. E.g. they can help others with using the element, but cannot make changes in the element without owners’ approval.

Operations exported by this connection target, e.g. module operations exported by its interface.

A persona may extend another persona. E.g. “Moderator” discussion forum persona extends “User” persona, which may in turn extend “Visitor” persona. This persona inherits goals for the extended personas.

Personas extending this persona.

Persona goals are used to elicit and align endeavors. E.g. new product features.

Issues (work items) for this element.

Markers pointing to where this model element was loaded from - location, line and column numbers. Multiple markers are supported for situations when a single model element is loaded from multiple locations, e.g. a row in an Excel document or a database and then pom.xml and readme.md is a source repository. Another possiblity is an element being created from a prototype and then loaded - in this case the object will inherit markers from its prototype and will have a marker point to the location where it was loaded from. Markers are listed in the reverse order, i.e. the prototype marker would be after the load marker in the list.

Element owners have both expertise and authority over the element.

Principles associated with this element to support decision making.

Pluggable representations of a model element, e.g. a component diagram for modules.

Engineers which represent this persona. E.g. in a hierarchical organization some units or engineers may build products for internal customers - other units or engineers. In this case some of those internal customers act as persona representatives and work with the persona owner to identify persona goals and product features to address those goals.

Resources associated with the element, e.g. documentation.

Sections for model element documentation.

Period start.

Table of contents configuration.

Discussion topics in this forum.