Re: Priority of Constituencies proposal

I like the idea of the Priority of Constituents. I feel like it helps keep
everyone grounded in the group's best interests rather than letting ego or
personal opinion get the best of us.

I wasn't ready to talk about this with the group yet, but since it's been
brought up I might as well mention it. I've been working with a few others
on iterating on the Microformats 2 JSON representation. The idea is to
bring it closer in line with what we see with more typical JSON APIs.

There is a stub page on the Microformats wiki
http://microformats.org/wiki/jf2 as well as the GitHub wiki page Harry
linked previously:
https://github.com/w3c-social/Social-Syntax-Brainstorming/wiki/Minimal-Activity-Stream

We're still iterating on it, but will have something to talk about during
the next telcon.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>


On Mon, Oct 26, 2015 at 8:12 PM, Harry Halpin <hhalpin@w3.org> wrote:

>
>
> On 10/26/2015 10:44 PM, James M Snell wrote:
>
> I've seen the very constructive feedback from Jason (
> https://lists.w3.org/Archives/Public/public-socialweb/2015Oct/0191.html).
> I'm quite certain that he can continue to speak for himself. As I said,
> based on the constructive feedback, tweaks are being made (
> https://github.com/jasnell/w3c-socialwg-activitystreams/pull/220). The
> most productive thing to do at this point is for potential implementers to
> keep feeding in *constructive*, *specific* discussion so that *specific*
> improvements can continue to be made. We won't make progress talking about
> process yet again.
>
>
> I think the process suggestion re "Priority of Constituencies" is rather
> common-sense - and still useful, as now in addition to specific feeback, we
> have an *alternative* syntax to AS2.0 being developed in the WG:
>
>
> https://github.com/w3c-social/Social-Syntax-Brainstorming/wiki/Minimal-Activity-Stream
>
> I'd prefer to have one spec. The "Priority of Constituencies" is one way
> to deal with situation where there is conflict between specs or designs. In
> addition, a co-editor for AS2.0 would be make sense, perhaps Aaron given
> the work on Minimal Activity Streams?
>
>        cheers,
>             harry
>
>
> On Mon, Oct 26, 2015 at 7:19 PM, Harry Halpin <hhalpin@w3.org> wrote:
>
>>
>>
>> On 10/26/2015 09:41 PM, James M Snell wrote:
>>
>> -1. I don't see this as being useful right now at all. A year ago, maybe. At this point in time for AS2, we are making decent progress again getting specific feedback from potential implementers and making improvements accordingly. All of the potential implementers who have spoken up have said that AS2 is at a good point but it just needs a few tweaks here and there. That is productive. What's being suggested here is not.
>>
>>
>> However, none of the implementers seem very thrilled (particularly with
>> some of the JSON-LD specific parts - see feedback from Diaspora or the
>> internationalization issue)  and quite a few are asking for
>> simplifications. In terms of simplifications and added complexity coming
>> from different communities, I think this rule served HTML5 well and it
>> would serve this spec well.
>>
>>                  cheers,
>>                       harry
>>
>> Sent from IBM Verse
>>
>>
>>
>> Harry Halpin --- Priority of Constituencies proposal ---
>>
>> From: "Harry Halpin" <hhalpin@w3.org> <hhalpin@w3.org> To:
>> public-socialweb@w3.org Date: Mon, Oct 26, 2015 6:29 PM Subject: Priority
>> of Constituencies proposal
>> ------------------------------
>>
>> I was discussing with some Social Web developers why this group was as
>> contentious, and it occured to me that one obvious problem is that we don't
>> have a clear priority of constituencies. This "Priority of Constituencies"
>> served HTML5 Working Group well, and I'd suggest we adopt it with one
>> change that acknowlegdges that we do have three very different communities
>> in the room trying to make a common interoperability format, each with
>> different design preferences (i.e. JSON, microformats, and RDF). Here's the
>> version from HTML [1]: "In case of conflict, consider users over authors
>> over implementors over specifiers over theoretical purity. In other words
>> costs or difficulties to the user should be given more weight than costs to
>> authors; which in turn should be given more weight than costs to
>> implementors; which should be given more weight than costs to authors of
>> the spec itself, which should be given more weight than those proposing
>> changes for theoretical reasons alone. Of course, it is preferred to make
>> things better for multiple constituencies at once." It's rather
>> common-sense but its important to be explicit about it. Now, I'd like to
>> take an amendment. There's three groups, each of which have different
>> definitions of theoretical purity: The JSON-using group who are not
>> terribly attached to JSON-LD and the details of AS2.0 but are interested in
>> a simple JSON format and has a number of implementers with a larger number
>> of end-users than the microformat space, a micro-format community that
>> prefers shipping around HTML with microformats and has very active
>> implementers, and another group around RDF/Linked Data that has at least
>> one active codebase. I suggest that we prioritize the demands for
>> theoretical purity based on number of users/authors. Thus, we prioritize
>> keeping JSON (ideally, as simple as possible) over microformats, and we
>> prioritize microformats over RDF. My logic is the community that passes
>> around JSON using HTTP URIs is magnitudes larger than the microformat
>> community, and the microformat community is rather about equal in size to
>> the RDF community - although the microformat community is more active in
>> terms of number of implementers. However, I firmly believe the RDF
>> community has valuable insights that need to be input into the space around
>> the use of URLs and multiple schemas, and so the final specs should be
>> acceptable to all communities. Yet if microformat or RDF-specific
>> processing is required, that 'pain' should lie on the implementers who want
>> to convert the format to RDF or to microformats, and not on the users,
>> authors, and JSON-based implementers [roughly in that order]. I hope that
>> makes sense and I think all communities will have to give and take, but
>> that's what consensus is about. cheers, harry [1]
>> http://www.w3.org/TR/html-design-principles/#priority-of-constituencies/
>>
>>
>>
>
>