Re: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt

[Ted Lemon <[e-mail]>]

This is an IRTF document, which will show up in the RFC series, and not a standard academic document.   If the goal is for this to be useful to the community of users for which the IRTF and IETF are the core, then it should look like an RFC, not like an academic paper.

This means that the abstract should be just long enough to tell the reader what is inside the package and why they should read it, and no longer.  It should not say anything about the structure of the RFC.

Similarly, it may be that an academic research paper can’t start with the research question because that’s the custom in academic research papers; if this RG has as its goal to speak only to the academic community, perhaps that is okay.  But then why publish it here and not in an academic journal?  Isn’t the point of doing academic work in the IRTF that it is part of the greater IETF community, and that its work is the production of useful RFCs?  Furthermore, if academic papers generally suffer usability issues (and IMHO they do), should we replicate those usability issues here, or should we do better?

Anyway, as I read through the rest of the response, it appears that you are simply disagreeing with my viewpoint.  That’s fine—I’m responding to Avri’s request for feedback with my opinion, not trying to speak authoritatively to you as the author.  I have made similar comments in the past, and not seen the document change as a result, nor seen my comments addressed.   Perhaps this document represents more views than just yours, but it certainly hasn’t captured my feedback.

As for the thicket of citations in the introduction, you have, at minimum, a usability problem here.  Don’t ask me to read past the thicket of citations.  Figure out a way to present these citations so that they are usable.   Your job as an editor is to produce a useful document; when you get feedback that makes the document less useful, you have to figure out a way to act on that feedback that is beneficial: it’s not enough to take the feedback in its original form and apply it, knowing that it’s making the document worse.

> On Sep 17, 2019, at 9:12 AM, Niels ten Oever <[e-mail]> wrote:
> 
> Dear Ted,
> 
> Thanks for this.
> 
> On 9/17/19 2:50 PM, Ted Lemon wrote:
>> On Sep 17, 2019, at 8:22 AM, [e-mail] <mailto:[e-mail]> wrote:
>>> I too am looking for RG guidance.
>> 
>> FWIW, the objections I raised probably a year ago haven’t been addressed yet.  An RG document should make a clear case for whatever point it’s making, but this document doesn’t do that.  The introduction is not really doing the job of an introduction—it starts with several quotes, and never really says what the document is about nor why we should read it.  
> 
> When the I-D started without references (not quotes), people said it should be based on existing literature and opinions within the IETF, and not on intuitions. Then I added these references to anchor the introduction documents. 
> 
> If Ted and the RG would prefer, I could also change around para 1 and para 2, but the academic way would be to start with embedding it in literature. I leave it to you all to let me know your preferences.
> 
> 
> Section 3 should be the introduction, and could start with the question stated there, and then give an overview of what the document talks about and what research methodology was used. 
> 
> It is highly unusual to start a paper with the research question (section 3.) and the methods (section 4). 
> 
>  The quotations in the introduction could either be chucked, or woven in appropriately, but as they are, they just prevent the reader from proceeding further.
> 
> Have you tried reading the sentences without looking at the references? Am also happy to remove them and connect the two paragraphs. As said, it are not quotes, but references to show that we are not making this up.
> 
>> 
>> The text from the abstract could be useful in the introduction; the abstract itself is meant to be a sales pitch for why you should read further and what the document is about, and so this one is way too long.
> 
> The abstract is 137 words, generally an abstract is 250 words in Science and Technology Studies, so am curious where this standards comes from. 
> 
>> 
>> The methodology that produced the subsections of 4 is unclear; it seems to be the author summarizing these viewpoints, but the author clearly has opinions about these viewpoints, and the summaries are difficult to follow and full of detail that is really part of the author’s conclusion,
> The titles of these positions are taken literally from this mailinglist and discussions in the session, and then built up further by embedding them with existing literature. 
> 
> Where do you see a bad representation?
> 
> 
>> and not part of the explanation of the position. So they aren’t really doing the job of helping us to understand the issues. 
> 
> It would be great if you could point out where so we can improve.
> 
>  Furthermore, we don’t know how the author decided to represent just these viewpoints, and no others, 
> 
> Because these were the viewpoints of 'positions that have been observed in the IETF and IRTF community, and have been observed during interviews, mailinglist exchanges, and during research group sessions.  These positions were observed during participatory observation, through 39 interviews'
> 
> nor is there any discussion of the relationships between these views, which I think clearly exist: they are presented as orthogonal.
> 
> Where? Happy to correct that.
> 
>> 
>> As an example of the difficulty of following these subsections, consider subsection 4.4.  We have an initial paragraph that explains the topic decently well, followed by a long quotation from Heidegger that explains it better, followed by a paragraph that introduces a new analogy, finally followed by a paragraph that tries to relate these analogies to the Internet and to protocols, but thoroughly fails to do so.  I think part of the reason it fails is that the author is really trying to express his view of how the Internet is analogous to the two examples he has given, and that distorts the analogy enough to make it quite difficult to follow.
> 
> 
> This was provided by Andrew Sullivan, not by me. But happy to correct.
> 
>> 
>> There are two major issues with this document as an RG document.  First, I don’t think it /is/ an RG document.  I think it’s the author’s document.  
> 
> Why, it has been adopted by the RG.
> 
> Secondly, it desperately needs a developmental edit.  I think the ideas being expressed here are probably worth expressing, but if it’s going to be Niels’ document, then Niels needs to get some outside feedback to turn it into a good document that says what Niels wants to say in a way is useful to other readers.  
> 
> I take issue with this description. There have been a lot of people who have contributed a lot of text to this document, among which Andrew Sullivan, Michael Rogers, and Amelia Andersdotter.
> 
> 
> And if it’s to be an RG document, then it needs to have more participation from the RG.  In order for that to happen, it probably needs Neils to be a contributing author rather than the editor, and for someone else to take over the editorial role.
> 
> Where does this rule stem from? This was not how we progressed with RFC8280.
> 
> 
> Best,
> 
> Niels
> 
>> 
>> 
>> _______________________________________________
>> hrpc mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/hrpc
>> 
> 
> -- 
> Niels ten Oever
> Researcher and PhD Candidate
> DATACTIVE Research Group
> University of Amsterdam
> 
> PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
>                   643A 0ED8 3F3A 468A C8B3
> 
> _______________________________________________
> hrpc mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hrpc