Re: New action on UCR group / Proposal for requirement numbering

Hi Jaro, Karen, All,

The two options for numbering seem OK to me, and I understand that the 
discrete index groups make it easier to work collaboratively on the 
document. If there is a strong feeling that the numbers should be 
continuous, this can be changed once the document is ready to be 
finalised IMO.

What I think it would be useful is to have the list of all the 
requirements in a single place/table, apart from appearing spread out 
through the document with explanations/notes, etc. This would allow to 
have a clear overview of the requirements and make them more visually 
prominent, as Karen mentioned. It would be great to try to extract them 
to a table with Javascript - otherwise, we can wait until they are stable.

The filtering options with the possibility of listing the requirements 
first is really useful (thanks Jaro!). Maybe the boxes for the two notes 
and 'Issue 1' could be removed from the list? It might also be useful to 
add a comment when there are no requirements or UCs in the results.

Thanks,

Alejandra



On 25/09/2017 14:10, Jaroslav Pullmann wrote:
> 
>   Hello Karen,
> 
>> issue is both having discrete numbers 
> 
>   this is covered by both approaches
> 
>> and having the requirements be visually more prominent
> 
>   there is the option to reverse the document order putting the 
> requirements in front of use cases.
>   I already ask for proposals / requirements of formating enhancements 
> with no resonance.
>   We may discuss the available options today, among others the 
> resolution and removal of
>   "note" and "issue" sections.
> 
>> At the moment, the requirements don't show in the table of contents
> 
>   hmm, they are located at the bottom of the page and not initially 
> visible,
>   but they are (as any other named section) part of the navigable TOC
> 
>> it's not easy to "eyeball" them in scanning the document. So the task
>> appears to be creating both numbers that we can refer to for clarity as
>> well as increased visibility of the requirements themselves. I'll let
>> others weigh in on whether the numbering below achieves that.
> 
>   yes, and if rejected a concrete proposal is need
> 
>> Other options include pulling the requirements into a separate document
>> where they are easily scannable, but that may be best done after they've
>> been approved. I can imagine that the editors of the three deliverables
>> will want to be working with a defined list of requirements.
> 
>   this is unusual, the use cases provide a mandatory interpretation 
> context.
>   All the W3C UCR specifications consulted maintain them as part of same 
> document.
> 
>   Talk to you soon, best regards
>     Jaro
> 
>>
>> On 9/23/17 4:53 PM, Jaroslav Pullmann wrote:
>>>
>>>   Dear Karen, dear all,
>>>
>>>   there were some discussions on the numbering approach for 
>>> requirements, among others:
>>>    1) continuous index: R1 ... RN:
>>>    PROS:
>>>   - straightforward
>>>    CONS:
>>>    - possibly high index numbers, potential for mistakes
>>>    - absolute index prevents distributed work (editors rely on mutual 
>>> changes of single shared index)
>>>    - purely numerical index, no relation among items
>>>
>>>   2) discrete index groups based on requirement's topic: RVers1 ... 
>>> RVersN, RProv1 ... RProvN
>>>
>>>   This approach involve the following steps:
>>>
>>>   a) for each requirement identify a topic / main tag, e.g. 
>>> "version". The assumption here is, that there should be at least
>>>   one such tag (otherwise to be create) and there a requirement 
>>> should be focused enough to map naturally to a single one
>>>
>>>   b) create ID using tag's mnemonic abbreviation and current index: 
>>> "RVers2". The index increments by group, not globally
>>>
>>>   PROS:
>>>   - easy to maintain small, "local" index
>>>   - distributed work possible
>>>   - items are naturally related
>>>   - makes use of and evaluates tagging
>>>   CONS:
>>>   - requires to decide on requirements main topic (which is indeed o.k.)
>>>
>>>   Personally I am in favor of option 2) and provided a sample 
>>> numbering of the whole requirement set here:
>>>
>>>        https://rawgit.com/jpullmann/dxwg/gh-pages/ucr/index.html
>>>
>>>   The example surely needs polishing but is stable enough to ask for 
>>> discussion of this approach in our next telcon.
>>>
>>>       Best regards
>>>     Jaro
>>>
>>> On Tuesday, September 19, 2017 00:33 CEST, Karen Coyle 
>>> <kcoyle@kcoyle.net> wrote:
>>>> After the call ended today I realized that I missed an opportunity to
>>>> create an action around Alejandra's suggestion that the UCR document
>>>
>>>> might need numbering for the requirements as well as their brief
>>>> headings. I will now create an action item with the description:
>>>>
>>>> Explore numbering of requirements within the heading areas in UCR 
>>>> document
>>>>
>>>> Because the tracker only takes one name, I'll assign this to a 
>>>> member of
>>>> the UCR group but the implication is that it is a group task. Note that
>>>> it says "explore" because the UCR group should come back to us if this
>>>> turns out to be overly burdensome.
>>>>
>>>> Thanks, kc & Caroline
>>>> -- 
>>>> Karen Coyle
>>>> kcoyle@kcoyle.net http://kcoyle.net
>>>> m: 1-510-435-8234 (Signal)
>>>> skype: kcoylenet/+1-510-984-3600
>>>>
>>>
>>
> 

-- 
Alejandra Gonzalez-Beltran, PhD
Research Lecturer
Junior Research Fellow at Kellogg College
Website <http://www.oerc.ox.ac.uk/people/alejandra> | ORCID
<http://orcid.org/0000-0003-3499-8262>
Address:
University of Oxford
Engineering Science
Oxford e-Research Centre
7 Keble Road, Oxford
OX1 3QG, UK
--

Received on Monday, 25 September 2017 13:27:10 UTC