Re: [hrpc] Possible options for a HRPC research publication

[Colin Perkins <[e-mail]>]

Hi,

There’s a lot of flexibility in how RGs can operate, and publishing RFCs is only one option.

For RFCs, consensus documents are certainly important, and are a common way for groups to operate, but consensus is certainly not a requirement. Provided that it’s clear why a document is being published, and whose opinion it represents, a document that articulates a non-consensus view can be valuable. It might even be more valuable if published alongside a critique or discussion of the counterpoint view. The IRTF can be reasonably creative in what RFCs it publishes. 

Outside of RFCs, IRTF groups have certainly held workshops in the past, and I'd encourage such activities. The RAIM workshop <https://irtf.org/raim-2015> was a good example of this, and the IAB workshops <https://www.iab.org/activities/workshops/> are perhaps another example that might be relevant. Such workshops often publish a workshop report as an RFC, but we could also work with an appropriate academic publisher to publish archival proceedings, or simply host position papers on the website as we did with RAIM. More formal workshops associated with academic conferences work for some research groups. Perhaps working with a journal might work for HRPC? 

Also, we can certainly be more creative in hosting research group content on irtf.org <http://irtf.org/>, where it makes sense to do so. If HRPC wants to host a curated set of resources, essays, commentary, etc., then we can discuss how to do that.

Think what makes sense to advance the research of the group, and we’ll try to figure out how to support it.

Cheers,
Colin




> On 8 Apr 2020, at 10:21, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> I like the idea of trying an "annual" (or "occasional")
> publication of people's works-in-progress. Sounds a bit
> like the proceedings of a workshop maybe? But however
> it's cast, I'd say, yes do try it.
> 
> One other point, maybe a nit: for me, the RG can be
> happy that a document is ready for publication even
> if there is not consensus on all of the content of
> the document. I think HRPC could do more to publish
> documents in that kind of state via inclusion of some
> well-written caveats/disclaimers.
> 
> Cheers,
> S.
> 
> On 08/04/2020 04:24, [e-mail] wrote:
>> Hi,
>> 
>> **
>> 
>> *Recently it has felt to me as though the HRPC RG was spinning its
>> wheels. Our documents aren't moving along the path to RFC very easily
>> and except for interesting presentations at meetings, well worth while
>> in themselves, we have not been making great progress with our research.*
>> 
>> *
>> 
>> Part of this comes from a disagreement about the use of RFC publishing. 
>> While I know it is not a requirement for the IRTF, I strongly believe
>> that research published as a RG RFC should have RG agreement for
>> publication. This does not mean that there must be agreement on all the
>> ideas and statements in the doc, but on the finished product. This was
>> the process we followed with RFC 8280 and I believe it works. A bit
>> cumbersome and slow at times, but it led to what I believe was a better
>> document. 
>> 
>> 
>> Not everyone, including my co-chair, agrees with this approach. To many,
>> the RFC series is the publication method used by the IRTF and not
>> everything needs to be a rough consensus document. In addition to
>> individual submissions, IRTF submissions are not bound by IETF rules.
>> They rightly ask why HRPC should be so strict when there is no
>> requirement to be. This question in one way or another has been asked by
>> several people in the RG over the last few years. The recent difficulty
>> has also been named as a reason for why researchers have seemed a bit
>> less willing to work on documents lately; what is the point if they
>> won't get published.
>> 
>> 
>> I can see this point of view, and yet, I still find myself unable to
>> support sending a RG document to the IRSG  that the RG does not think is
>> ready for publication. Of course individual submissions would be a
>> different matter as those do not need to be shepherded by the RG chair
>> in the same way.
>> 
>> 
>> Mallory and I have been discussing this impasse on and off for the last
>> two years. The last time we talked we both felt, I believe, that it was
>> time to try something different to break the impasse.  I made a
>> suggestion for working with two tracks, one the RFC track where RG
>> internet drafts need RG support for publication as RFCs, and the other,
>> the production of a yearly publication that is an edited volume that
>> does not require RG approval. Mallory suggested that I bring this to the
>> RG for discussion.
>> 
>> 
>> What I am suggesting for the non RFC track is that we pick a topic per
>> year and publish a collection of research, essays, and commentary on
>> that topic. How we would publish this remains to be discovered; could be
>> anything from a wiki site to an ebook or even finding a journal to do a
>> special release, if such a thing is possible. Mallory and I would act as
>> lead editors, but we would need to enlist help from members of the RG in
>> terms of putting such an effort together, as it does take work and
>> contributions.
>> 
>> 
>> In terms of topics for a first year, I have thought of two, but am not
>> wed to either of them at all. We would need to find a subject that
>> members of the RG, and hopefully others, would be willing to contribute
>> their writing to.
>> 
>> 
>> 1 - Take the draft-politics as the seed and build the edition around the
>> various aspects of that discussion and the issues it raises.
>> 
>> 
>> 2 - Take the HRPC core question on “whether standards and protocols can
>> enable, strengthen or threaten human rights” and explore the various
>> viewpoints on that question, including the pros, the cons and anything
>> in between.
>> 
>> 
>> This topic is on our upcoming meeting agenda, and I hope to gather some
>> viewpoints that will guide how we can move forward, or not as the case
>> may be, with the idea. Also interested in opinions on the list.
>> 
>> Thanks
>> 
>> avri
>> 
>> 
>> *
> <0x5AB2FAF17B172BEA.asc>


-- 
Colin Perkins
https://csperkins.org/