W3C home > Mailing lists > Public > public-credentials@w3.org > December 2020

Re: Manifesto: Rules for standards-makers by Dave Winer

From: Liam McCarty <liam@unumid.org>
Date: Thu, 17 Dec 2020 12:02:10 -0600
Message-Id: <52F3AE79-EBBD-4D33-AF4C-24A245FF6E4F@unumid.org>
To: "W3C Credentials CG (Public List)" <public-credentials@w3.org>


Liam McCarty
Co-Founder of Unum ID

> On Dec 17, 2020, at 2:02 AM, Phillip D. Long <phil@rhzconsulting.com> wrote:
> 
> The latest two posts by Daniel Hardman and Leonard Rosenthol are quite complementary and provide perspective to the deeply pragmatic approach that Dave Winer advocated in his 2017 Manifesto: Rules for Standards-makers. 
> 
> I certainly agree that all standards need to be thought of in term of a life-cycle, and that most importantly, and most often  missing is when should they ’sunset’? But Daniel reminds us that there needs to be a good deal of groundwork, and earned experience before useful implementable standards can emerge. I sense some of that urgency in the VC work, when we haven’t yet fully accounted for all the critical pieces of that ecosystem, nor have we built much depth of implementation experience with DiDs. That’s in part because we really haven’t done the homework yet to understand what individuals we expect will be use these need, want and fear should the rush to implementation gather steam. End user driven or at least deeply informed use cases can be very helpful here.
> 
> While I appreciate the admonition that no matter how much better the new way is, you have to support the old way, I do think that you have to do this be providing sufficient bridges and encouragement from the value gained by the new way in the process. I guess continuing to support a vast embedded user base of Windows 95 OSs even after MS deprecated its own support for it was helpful that user community, but I’m not sure how helpful that really was in the longer term view of it. It’s always hard and most times costly to step into a new paradigm, but that’s especially true if the change made doesn’t benefit majority of the community for whom the new standard is intended. 
> 
> It is all about interoperability. That is I think a fundamental truth. But interoperability without demonstrable value that can be clearly conveyed in concise language and doesn’t require deep understanding and sophisticated nuance to appreciate trumps the rest. 
> 
> Any thread that makes you think hard before responding is valuable. Thanks for catalyzing this on Heather!
> 
> Phil
> 
> Phillip Long, Ph.D., T3 Innovation Network, LER Pilot Projects Community Manager
> e: phil@rhzconsulting.com, 
> SNS: Twitter/Telegram @RadHertz
> LinkedIn: https://www.linkedin.com/in/longpd
> —
> RHz Consulting, LLC.
> Inquire-Listen-Design-Prototype-Analyze-Repeat
> e:phil@rhzconsulting.com
> LinkedIn:http://www.linkedin.com/in/longpd
> —
> Senior Scholar, Georgetown University
> Center for New Designs in Learning & Scholarship (CNDLS)
> e: pl673@georgetown.edu
> — 
> Special Advisor & Faculty Affiliate, 
> Arizona State University
> e:pdlong2@asu.edu
> 
> Schedule me: https://calendly.com/phil-t3/45min
> 
>> On Dec 15, 2020, at 12:19 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> 
>> > When should something be standardized?
>> > 
>> I’d expand on that a bit by pointing out that you really need to think about this in the “lifecycle of a standard”.  
>>  
>> Consider the *starting* the standardization effort – such as this CG.  The existence of W3C’s CGs, ISO AhG (AdHoc Groups) or DG (Discussion Groups) and the use of other organizations (eg. Alliance for Open Media or DIF) as incubators also help here too.  The earlier you start things to start gathering input from the industry and SMEs the better, IMO.  I’ve been enamored recently with some ISO committee’s approaches of doing a Use Case/Requirements specification *first* before even considering the technical matter.  Not unlike what we do in software, of course.
>>  
>>  
>> >* When should a standard be abandoned or replaced?
>> > 
>> We were just talking about this at an ISO meeting this morning concerning a standard from 2003 that is up for systematic review (ISO terminology for “should we kill it yet?”).   While the general consensus is that that vast majority of the document is out of date (and not aligned with the modern way of doing things) there are still a few key areas that remain relevant.  More importantly, there are national standards (very popular in the EU) that refer to it.   The other problem is that *NO ONE* is willing to step up and work on an update ☹.  
>>  
>>  
>> Leonard
>>  
>> From: Daniel Hardman <daniel.hardman@evernym.com>
>> Reply-To: "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>
>> Date: Tuesday, December 15, 2020 at 11:07 AM
>> To: Steve Magennis <steve.e.magennis@gmail.com>
>> Cc: George Lund <george.lund@digital.cabinet-office.gov.uk>, Heather Vescent <heathervescent@gmail.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
>> Subject: Re: Manifesto: Rules for standards-makers by Dave Winer
>> Resent-From: <public-credentials@w3.org>
>> Resent-Date: Tuesday, December 15, 2020 at 11:05 AM
>>  
>> There's lots of excellent wisdom in Dave Winer's post. Good stuff.
>> 
>> However, the post is silent about two questions that I also feel should be part of battlescar-driven standards advice:
>> 
>> * When should something be standardized? (I think it is possible to open a conversation about standardizing something far too early, when there is not enough implementation experience to inform the pragmatism Winer advocates. Perhaps it is also possible to standardize too late... It would be interesting to explore that.)
>> 
>> * When should a standard be abandoned or replaced? (Software, and software standards, should have an end of life. I don't think we -- that's the whole software industry, not just standards builders or identity circles -- manage this well. Seehttps://codecraft.co/2012/09/28/the-8th-characteristic/)
>>  
>> On Tue, Dec 15, 2020 at 8:50 AM <steve.e.magennis@gmail.com> wrote:
>>> I resisted as long as I could 😊
>>>  
>>> Corollary to ‘Write specs in plain English’:  ‘Don’t write specs that only make sense to people who already understand the spec’
>>> A spec attempts to precisely document something but it is also there to inform others so that they can use the spec and build things upon it. Most specs I’ve worked with emphasize comprehension over clarity, some even seem to take pride in the fact that only a small group of people have the context to really understand them.  I think there needs to be a good dose of both comprehensiveness and clarity. It drives me crazy when I have to read 20 pages of supporting material just to get through the first paragraph.
>>>  
>>> -S
>>>  
>>> From: George Lund <george.lund@digital.cabinet-office.gov.uk> 
>>> Sent: Tuesday, December 15, 2020 2:16 AM
>>> To: Heather Vescent <heathervescent@gmail.com>
>>> Cc: W3C Credentials CG (Public List) <public-credentials@w3.org>
>>> Subject: Re: Manifesto: Rules for standards-makers by Dave Winer
>>>  
>>> Hi all
>>>  
>>> Love this document, and there's little to fault at all. My only critique would be that "It totally doesn't matter what we call it" isn't really a corollary of "Perfection is a waste of time", for me.
>>>  
>>> I'd say that naming things is hard, and one mustn't try to be completely right first time. But the confusion that can persist when something is incorrectly named, and that name is allowed to live on despite actual practice, can be very damaging in the long run. You end up with a situation where something is "obvious" to those with long experience in a field, but commonly misunderstood by those working on the edge of it or engineers (experienced or not) coming new to a topic. A good format (for example) allows a new version to be rename things as needed, with old names marked as a deprecated aliases (or whatever is appropriate).
>>>  
>>> Clarity of language is even more important when communicating with people whose first language isn't English, not less so - the "symbols" thing is just wrong I think.
>>>  
>>> George
>>>  
>>>  
>>> On Mon, 14 Dec 2020 at 22:57, Heather Vescent <heathervescent@gmail.com> wrote:
>>>> Interesting piece by Dave Winer. What do you agree with? What do you disagree with?http://scripting.com/2017/05/09/rulesForStandardsmakers.html
>>>>  
>>>> -H
>>>>  
>>>> --
>>>> Heather Vescent
>>>> Co-Chair, Credentials Community Group @W3C
>>>> President, The Purple Tornado, Inc
>>>> Author, The Secret of Spies (Available Oct 2020)
>>>> Author, The Cyber Attack Survival Manual (revised, Dec 2020)
>>>> Author, A Comprehensive Guide to Self Sovereign Identity
>>>>  
>>>> @heathervescent | Film Futures | Medium | LinkedIn | Future of Security Updates
>>> 
>>> 
>>>  
>>> --
>>> George Lund
>>> Senior Developer for GOV.UK Verify
>>> Government Digital Service
> 

standards.png
(image/png attachment: standards.png)

Received on Thursday, 17 December 2020 18:02:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 17 December 2020 18:03:01 UTC