Help:Contents:Issue

From Cicero

Jump to: navigation, search

Contents

The Issue Overview Page

For each issue, an overview page and a discussion page exists. The overview page of an issue can be reached from the project overview page: Either the list of the 10 most recently added issues can be used for accessing an issue (see area 3 in Fig. 4) or the options Search for Issues and List all Issues can be used (see area 2 and 3 in Fig. 4). The issue overview page has three main areas that are shown in Fig. 11:

  1. A description of the issue as it was entered during the creation.
  2. A list of all solutions for the issue that were proposed up to now. If the description of a solution proposal is too long only the first 30 words are initially shown. One can expand the description to its full length by using the lens at the end of the corresponding description. This area also shows which solution is selected for implementation once a decision is taken (see the Subsection about Taking a Decision ).
  3. An overview box with the most important properties of the issue, e. g. who created the issue, how many solutions are proposed and how many arguments are given. Furthermore, one can access from here the full discussion associated with the issue or change the properties of the issue. In order to see the Change Issue Properties option, one needs to have the corresponding access right (see the Subsection about Managing Access Rights and User Roles).

The issue overview page is automatically generated and updated by Cicero and need not be changed by the user. The description and the settings of the issue can be changed in the issue properties (see the Subsection about Managing the Issue Properties).


Figure 11: Overview page of an issue in Cicero.

Creating an Issue

New issues can be added by using the corresponding option on the project overview page (see area 2 and 3 in Fig. 4). In order to see the Add New Issue option, one needs to have the corresponding access right (see the Subsection about Managing Access Rights and User Roles). Creating a new issue is a simple task in Cicero and can be done very fast. In the form for creating a new issue (see Fig. 12) one only needs to enter a unique title for the issue and an initial description. The description may contain Wiki markup for formatting, including links to related issues or web pages.


Figure 12: Form for creating a new issue in Cicero.

The issue is then created by clicking on the Save Issue button. The settings with regard to the decision taking procedure and the issue and voting timer are set to the default values as they are specified in the project settings (see the Subsection about Advanced Project Seetings). The settings and the text describing an issue can later be changed on the page for managing the issue properties (see the Subsection about Managing Issue Properties).

Issue States

During its lifetime, an issue passes through four different states. Depending on the state, different changes to the issue are allowed. The states are summarized below and in Fig. 13:

  • Running: During the running state, all users with the corresponding access rights are allowed for making changes to the issues like adding further solution proposals or arguments.
  • Locked: An issue can reach the locked state only if the dictator mode is chosen for decision taking (see the Subsection about Taking a Decision). During the locked state, no changes to the issue are allowed. Only a user with the corresponding access rights is allowed for deciding which solution proposal should be implemented as a response to the issue. As soon as the decision is taken, the state automatically changes to the decided mode.
  • Voting: An issue can reach the voting state only if a preferential voting is chosen for decision taking (see the Subsection about Taking a Decision). During the voting state, no changes to the issue are allowed. All users with the corresponding access rights are allowed for casting their ballot. The voting is finished either after the time span set in the voting timer or it is manually finished by a user with the corresponding access rights. As soon as the decision is taken, the state automatically changes to the decided mode.
  • Decided: As soon as a decision is taken which solution proposal should be implemented in response to the issue, the issue changes into the decided state. In this state, no changes to the issue are possible. If it should be further discussed, the issue has to be set back to the running state by a user with the corresponding access rights.


Figure 13: Issue States in Cicero

The Discussion Page

The discussion page is - as the name says - the place where the discussion of a certain issue is stored. It can be reached from the issue page either through the tab-bar at the top or through the View Discussion link in area 3 of the issue overview page (see Fig. 7). At the top of the page a table of content of the whole discussion is shown for quickly accessing specific solution proposals or arguments (see area 1 in Fig. 14). Directly below the table of contents, the subject of discussion, i. e. the description of the issue, is repeated from the overview page.


Figure 14: Discussion page of an issue in Cicero.

Below the subject of discussion, the different solution proposals and their supporting or objecting arguments are listed. To make a contribution to the discussion, one has to use the Reply link next to the corresponding heading to which it should refer. Two different kinds of contributions can be distinguished:

  • Solution Proposal: As the name says, it proposes a possible solution of the current issue. During taking a decision, one can select one or more solution proposals for being implemented as a response to the issue (see the Subsection about Taking a Decision).
  • Argument: In principle, an argument can either support or object a specific solution proposal. Three different types of arguments exist:
    • Example: An example corresponds to a pattern that should or should not be imitated (depending on whether its a supporting or objecting example). They are used for illustrating similar cases that may serve as a model for the solution proposal to which they reply.
    • Evaluation: An evaluation gives criteria which help to assess the strengths and weaknesses of a solution proposal.
    • Justification: A justification describes the relevant circumstances that help to understand why a certain solution is supported or objected by the author of the argument.

In Fig. 15, the form for adding an argument to a solution proposal is shown. In the top left drop down list, one can select the argument type and whether it supports or objects the solution proposal to which it replies. In the box below, the argument text can be entered. The text may contain Wiki markup for formatting, including links to external resources or files uploaded to the Wiki.


Figure 15: Form for replying to a solution proposal.

The different kind of contributions and how they are related to each other can also be seen in Fig. 16. One can see that solution proposals can only directly reply to the issue while the arguments can only directly reply to a solution proposal. This results in a very flat hierarchy, showing the arguments with a small indent to their solution proposals.


Figure 16: Relations between issues, solution proposals and arguments.

Taking a Decision

If the decision taking procedure for an issue should be started, the state of the issue has to be changed from running to voting first. Under the precondition that there exists at least one solution proposal on the discussion page of an issue, two different ways exist how this state transition may take place:

  1. In the issue settings, an automatic issue timer can be set that triggers that transition of the issue state from running to voting. By default, the issue timer is deactivated but in the project or issue settings a specific number of days may be given after which this transition takes place (see the Subsection about Advanced Project Settings and Managing Issue Properties).
  2. A user with the necessary access rights (see the Subsection about Managing Access Rights) edits the issue properties and manually starts the voting phase for an issue.

Furthermore, two basic modes for taking a decision can be distinguished:

  • Preferential Mode: In the voting phase of the preferential decision mode, all users with the corresponding access right can cast their ballot. Either automatically, by means of the voting timer determined in the issue settings (see the Subsection about Managing Issue Properties), or manually by an authorized user, the voting phase is closed after some time and the solution proposal with the most votes is marked as the decided solution. In case of a draw between two or more solution proposals a run-off ballot will start automatically. As soon as a final decision is available, the results are shown on the issue overview page and the state of the issue automatically changes to decided.
  • Dictator Mode: In this mode, a user with the corresponding access rights locks the issue (see the Subsection about Managing Issue Properties). After that, he may go back to the issue overview page where a link to the page for taking a decision is shown. Once, the user made his decision he returns to the overview page where the result is shown and the issue state automatically changes to decided. Thus, the decision is only made by a single user.


Figure 17: Issue overview page during a running preferential voting.

Depending on the selection mode of the issue (see the Subsection about Managing Issue Properties), the users can either select only a single solution proposal during the decision taking phase or multiple solution proposals. In Fig. 17 shows how the look of the issue overview page during a running preferential voting. By clicking on the button in the upper-left box, the user can change to the page shown in Fig. 18 and cast his ballot. For the dictator mode both pages look very similar.


Figure 18: Form in Cicero for casting the ballot during a voting.

Managing the Issue Properties

The properties of an issue can be changed by choosing the corresponding option on the issue overview page (area 3 in Fig. 7). This option is only available for users with the corresponding access rights. In the issue properties (see Fig. 19), one can change the description of the issue (area 1) as well as its advanced settings (area 2). The description may contain Wiki markup for formatting, including links to related issues or web pages. The values of the advanced issue settings are inherited from the project settings during the creation of the issue (see the Subsection about Advanced Project Settings). More details on the meaning of the different settings are available in the sections about the different state of an issue and the available decision taking procedures (see the Subsection about Issue States and Taking a Decision).


Figure 19: Editing the issue properties in Cicero.

The issue timer and the voting timer can be used for automatically triggering issue state transitions. The issue timer gives the number of days after which an issue should automatically change from the running state into either the voting or locked state, depending on the chosen decision mode. The voting timer gives is only activated if preferential voting is chosen as the decision taking procedure. In this case, it gives the number of days after which the voting is automatically closed. Setting either of both time spans to a value of 0 corresponds to deactivating the automatic state transition, i. e. a user with the corresponding access rights has to manually change the state with the help of the issue state drop-down list.

Deleting (deactivating) an Issue

The deletion (deactivation) of Issues is done analogous to the deletion of Projects as described in the Section about Deleting or Deactivating Projects.

(Re-)Activating an Issue

The (re-)activation of Issues is done analogous to the (re-)activation of Projects as described in the Section about Reactivating a Project.


[ back ] [ Contents ] [ next ]
Personal tools