REP 2004 extras

[maryaB-osr]

First commit, haven't read/edited fully yet:

• rearranged/rewrote abstract and motivation
• removed [ROS Core] points
• numbered requirements
• added DCO to change control level 1
• moved description to rationale
• added reference implementation content
• removed s.o. link
• small edits

Signed-off-by: maryaB-osr marya@openrobotics.org

[maryaB-osr]

one reason leaving all the written sections with the chart doesn't work is that the auto numbering makes it so the requirements' numbers don't all match level 1. for example, level 1's 2.iv is Must have Continuous Integration (CI) policy for all change requests but for level 2 the same requirement is listed as 2.ii because it doesn't have all the other requirements level 1 does. this makes the numbered rows in the chart slightly ambiguous because 4.i means different things for different levels.

this can be fixed by manually numbering requirements in the lists for 2+ to match level 1, or rearranging the requirements in level 1 so they match the order in which they're deprecated in the following levels.

didn't do any of this yet because we don't know what we're doing with the chart yet.

[maryaB-osr]

this one was hard to map to the chart because it's not recommending any specific step of the change control process, just the whole thing. so that would mean a ● for level 4's 2.i - 2.v, but 2.ii, 2.iii and 2.v aren't even "recommended" for levels 2 and 3. why would level 4 be more stringent than 2 and 3? so I just mapped this statement to 2.i alone but that's not really accurate

[wjwwood]

Yeah, the point of this was "all things under change control are optional, but recommended", but it isn't precise. I'm not sure what to do here, what do you think we should do?

[maryaB-osr]

Well, "all things optional, but recommended" is kinda the case for everything right? based on line 59:

While each quality level will have different requirements, it's always possible to overachieve in certain requirements even if other requirements prevent a package from moving up to the next quality level.

That doesn't mean we should put a dot in every spot on the chart though.

I guess the better question is are any of the steps highly recommended for level 4?
Levels 2 and 3 don't require or even highly recommend having DCO, a peer review policy, or documentation for all change requests.
So I think it's safe to assume what you're highly recommending is just the first point, all changes must go through a change request.
And so maybe it's a good idea to change this line to:

Suggested change

	#. No explicit change control process required, but still recommended
	#. No explicit change control process required, but it is recommended all changes occur through a change request.

[wjwwood]

I'm wondering about the wording here, maybe it should be more like:

Must check for a Developer Certificate of Origin (DCO) <https://developercertificate.org/>_ on changes

I'm not sure?

@mjcarroll what do you think?

[maryaB-osr]

@wjwwood not sure if this accurately generalizes the DCO requirement