DiscussionOnJIRAConfiguration < LHCb

LHCb Web>LHCbComputing>DiscussionOnJIRAConfiguration (2013-11-11, BenjaminCouturier) (raw view)
---+!! Discussion on JIRA Configuration

During the [[INDICO:236650][LHCb Computing Workshop]] it has been decided to prepare a list of requirements and use cases that must be fulfilled by the IT JIRA service.

This page can be used to collect such requirements and use cases in order to prepare the upcoming discussion with IT.

*For the editors*: when you add a new _user story_, please, create a section and add a brief description of what you would like to achieve. For example:
<verbatim>
---++ custom notification scheme
We need to be able to send a mail to a specific e-group for any update of an issue...
</verbatim>

---+!! Table of Contents
%TOC%

---+ User Stories

---++ Why so many options for the type of issue?

Rob Lambert: For what we nominally want to do, the types of issue are "report", "request", "suggestion", for issues, and some sort of story or work log for tasks. However in Jira we get a huge list of possible issue types to choose from, which is very disconcerting.

Ben Couturier: I agree, this is very confusing for occasional users of JIRA. The same is valid for other fields  than issue types, like for example the link types...

---++ Mailing list configuration

Rob Lambert: it looks pretty difficult to get the exact mailing list specification correct such that only a small number of people are notified of new bugs, but many people can submit new bugs. Wouldn't it be better to have a default configuration which worked out-of-the-box for almost anyone? With only a very small list of specified people to recieve emails? Could it not be made simpler for the users to see what emails they are subscribing to, and to subscribe/unsubscribe themselves through Jira directly?

---++ *Customization of fields*...

Rob Lambert: In the current configuration, fields are shared across projects and across experiments. The settings are maintained by CERN IT centrally and as such it takes a significant downtime for modifications to be made, if they are made at all.

Subsections below can be used to add other comments about the fields.

---+++ ->Priority *and* Severity

Rob Lambert: It's one of "the seven habits of highly effective people" that tasks be ranked in terms of urgency and importance separately. In savannah speak this was Priority and Severity, since our fields were customizable. Some times bugs may be very minor, but also be critically urgent due to an upcoming release deadline, and visa-versa. It would be good to see this reflected in the fields.

---+++ Implementation of Customizations

Ben Couturier: In Savannah, it was possible for the project administrator to customize some of the fields without contacting support. Will it be possible to have such features (with JIRA 6 for example) as it would save a lot of time.

---++ Installation of plug-ins/extensions

Marco Clemencic: for example we need syntax highlighting for Python, bash and C++. JIRA comes with syntax highlighting for Java and Javascript, but it can be enhanced with a plugin: https://plugins.atlassian.com/plugins/jira.plugin.syntaxhighlighter.macro.syntaxplugin


---++ Workflow Customizations

Ben Couturier: Some projects, like the simulation are using Jira to manage requests from many users, and there is a need to workflow customization (different default assignee/component is not enough I believe) to go through a list of steps.

Some changes could also be done to the default workflows: the Waiting for 3rd party is very commonly used...


---++ Reminder when a task / bug is approaching the deadline

Gloria Corti: Unless somebody regularly checks JIRA to know which topics are assigned to him and not yet resolved, things can be forgotten. Given that there is a due date for a topic, it would be nice if the person to which it has been assigned is reminded by email once the date is reached if the topic is still open. It would also be good if the project (or component) manager could trigger sending a reminder.

---++ Why issues can only be created by developers? <This is now fixed>

Gloria Corti: In the permission schema for LHCBGAUSS only Developers can create issues. While I think that is fine for deleting or moving issues I think any user should be able to report a bug. I don't think it is a good idea to give the lhcb-general mailing list the role of Developers either. I see that one can select a different permission schema, but how do I do that? If it is IT that does it we may want to see about a customized LHCb permission schema
Topic revision: r8 - 2013-11-11 - BenjaminCouturier
LHCb
Public webs
Welcome Guest
- Cern Search
- TWiki Search
- Google Search
LHCb All webs
Copyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback