Ticket #4 (closed enhancement: wontfix)

Opened 8 years ago

Last modified 2 years ago

Additional category(s) of requirement?

Reported by: chrish@… Owned by: pyilmaz
Priority: minor Component: environmental packages
Version: 2.2 Keywords: requirement
Cc: Sensitive: no


For future releases of the check list are there any plans for coming up with another category of requirement in addition to mandatory, conditional mandatory and optional, e.g. highly recommended (or is that what conditional mandatory means?), recommended etc.

This would allow the addition of a few extra fields to each of the environment package specific lists but keeping them small enough not to scare users off.

By way of an example, the host associated sheet would contain the "host_common_name" and "host_taxid" (among others) as highly recommended (HR).

Change History

comment:1 Changed 8 years ago by rkottman

I want to emphasize that how I understand Chris'
request is that we already have "conditional mandatory" which seems to be
what Chris suggests with highly recommended. If this is the case, I would
prefer the term "Highly recommended" over conditional mandatory.

comment:2 Changed 8 years ago by pyilmaz

I wanted to add a bit more to Renzo's mail, but I didn't want to bother everyone with details, so it is good we have a ticket.
I don't really perceive conditional mandatory and highly recommended as the same thing. The first one is saying a field should appear in the report if the study is fitting, but the other one is saying it is a good thing to have. Plus, wouldn't be confusing to have both highly recommended and recommended together?

comment:3 Changed 8 years ago by rkottman

ok, like Pelin defines it it would be different. But I do not see any prblem to have "recommended" and "highly recommended" next to each other. In fact, it much more clear to many people, because it is common to use "recommended" and "highly recommended" in standard speciifcations.

comment:4 Changed 8 years ago by pyilmaz

Well, the two terms are ranked; one is high, the other one is nothing. Therefore, it creates this illusion of one of them being less important, but that is not really the point we want to make. We have fields that we believe are vital info, then others which are not vital but can prove useful. Also, most people reading the checklists wouldn't really have prior experience with standards specifications (I didn't).

comment:5 Changed 8 years ago by anonymous

I thought the idea of the checklist has evolved into something that can accommodate all eventualities, which inevitably means it has multiple "optional" fields. With additional categories we could provide a method by which one can prioritize the list to enable the bare minimum to be embellished easily with "commonly" included information. We don't have the option to make most of the optional fields mandatory or even conditional mandatory as its just not always practical to require them in every circumstance.
I think this will be particularly important if (as is now) we have env package specific sheets, users are likely to ignore all other sheets and only fill in the fields requested on the relevant one they are using.
It will also give developers a "community endorsed" list of common fields to include as default on submission forms (with the option to expand to all fields of-cause), which is basically what I intended to do with the ENA submission forms (eventually).

comment:6 Changed 7 years ago by rkottman

  • Keywords requirement added
  • Summary changed from Aadditional category(s) of requirement? to Additional category(s) of requirement?

comment:7 Changed 7 years ago by pyilmaz

  • Status changed from new to assigned

Will work on possible 'highly recommended fields' in env package fields in upcoming months

comment:8 Changed 2 years ago by pyilmaz

  • Status changed from assigned to closed
  • Resolution set to wontfix
Note: See TracTickets for help on using tickets.