Re: Post Type Discovery

On 7 October 2015 at 16:38, elf Pavlik <perpetual-tripper@wwelves.org>
wrote:

> On 10/07/2015 03:42 PM, Melvin Carvalho wrote:
> > On 7 October 2015 at 12:47, elf Pavlik <perpetual-tripper@wwelves.org>
> > wrote:
> >
> >> On second thought I will +1 accepting it as Editor's Draft if it does
> >> NOT commit us to publish it as Working Draft, we will need to reach
> >> consensus before doing it. IMO working on it together will provide
> >> chance for us to develop better understanding of similarities and
> >> differences in modeling currently recommended in AS2.0 (W3C Working
> >> Draft) and Microformats (Independent Drafts). So far I only saw one
> >> effort in that direction between James and Tantek:
> >> * https://www.w3.org/wiki/Activity_Streams/Microformats_Mapping
> >> and multiple efforts by Amy:
> >> * http://rhiaro.co.uk/tag/socialwg
> >>
> >> What I see promissing here:
> >> https://indiewebcamp.com/post-type-discovery#Next_steps
> >> <blockquote>
> >> if accepted as an Editor's draft in the W3C Social Web Working Group:
> >>  * keep a copy on the W3C wiki, e.g.
> >> https://www.w3.org/wiki/Post-type-discovery
> >>  * use W3C Social Web github for issues
> >>  * use #social on irc.w3.org for discussion - both of which, officially
> >> *instead of* email. Unofficial discussion are of course encouraged
> >> anywhere people want!
> >>
> >
> > I would caution of using IRC *instead of* email, but rather, *in
> additions
> > to*.  The mailing list is a normative communications channel in a WG.  In
> > order to remain in good standing, participants are required to follow
> > relevant topics in the mailing list.
> Less that mailing list, I see github issues as very useful channel which
> offers features like nicely formated code snippets, inline images and
> other perks which come with flavored markdown. I also aligns with Modern
> Tooling effort
>
> https://w3c.github.io/modern-tooling/#de-facto-github


Agree this is valuable.  But the mailing list is critical to make progress,
and a WG requirement see:

http://www.w3.org/Consortium/Process-20010719/groups.html#good-standing
4.2.4 Good Standing in a Working Group

Participation on an ongoing basis implies a serious commitment to the
Working Group charter, including:

   - being familiar with the relevant documents of the Working Group,
   including minutes of past meetings.
   - following discussions on relevant mailing list(s).


This has been a problematic area for this WG as per attempts to circumvent
it, leading to lost time and progress.

https://www.w3.org/wiki/Socialwg/2015-04-14-minutes#resolution01

On a number of occasions, people have shown up to the the telecon only to
find important members are unaware of the relevant discussions, and costing
the limited telecon time that we have.

So while modern tooling is great, and can be very helpful, the mailing list
is the canonical area that we all follow.  And Indeed, it's a W3C
requirement for good standing.


>
>
> >
> >
> >> end if
> >> </blockquote>
> >>
> >> On 10/06/2015 11:34 PM, elf Pavlik wrote:
> >>> On 10/06/2015 08:12 PM, Evan Prodromou wrote:
> >>>> I objected today to accepting PTD as a working draft because I have
> some
> >>>> open questions about it, and not because I think there's an intrinsic
> >>>> problem with the doc. I'm not sure if they're appropriate for the
> >>>> document feedback section, since they're less about the format itself
> >>>> and more about the relationship with this group.
> >>>>
> >>>>  * *Does this fit with our charter*? In other words, can we argue that
> >>>>    taking on this work as part of the WG is related to the work that
> >>>>    we're supposed to be doing?
> >>>>  * *Do we have the bandwidth for it*? As a working group, do we have
> >>>>    the time and attention to work on this document and move it
> forward?
> >>>>  * *How does it relate to our other deliverables*? Is it a replacement
> >>>>    for the JSON-based social data syntax, or kind of a preprocessing
> >>>>    best practice?
> >>>>  * *Who will work on the document? *Who will be shepherding this
> format?
> >>>>  * *What are our success criteria*? Are we intending to publish this
> as
> >>>>    a Note or Recommendation? Or is it there to inform implementers of
> >>>>    the other specs? Or are there other goals for continued work with
> it?
> >>>>
> >>>> I really appreciate the effort that's gone into this document, and I
> >>>> think it's well-written and has a lot of value. I just want to make
> sure
> >>>> that we know the work and responsibility involved, if any, before we
> >>>> adopt it into the group.
> >>>
> >>> I added issue on IWC wiki
> >>> * https://indiewebcamp.com/post-type-discovery#Issues
> >>>
> >>> I see current claim of compatibility with AS2.0 very misleading and
> >>> purely based on included in AS2.0 drafts examples of Microformats HTML
> >>> serializations, about which James wrote a clear NOTE in both specs:
> >>> "The Microdata, RDFa and Microformats examples included in this
> document
> >>> are purely informative and may not currently reflect actual
> >>> implementation experience or accepted best practices for each format.
> >>> These alternate serializations may be removed from future iterations of
> >>> this document and moved to a separate informative WG Note."
> >>>
> >>> As of today Post-Type-Discovery only applies to modeling used by
> >>> participants of IndieWebCamp and assumes use of Microformats
> Vocabulary.
> >>>
> >>> I don't say that I support modeling used by IWC based on Microformas
> >>> Vocabulary or that I support modeling used by James based on
> >>> ActivityStreams 2.0 Vocabulary. I just think that pretending that those
> >>> two mentioned use compatible models, and that proposed 'type discovery'
> >>> supports both, only brings more confusion to current state of things.
> >>>
> >>> If supporters of this draft really want it to support both Microformat
> >>> and ActivityStreams 2.0 based modeling, I see appropriate to show it
> >>> with examples which use *both* recommended AS2.0 modeling and
> >>> recommended Microformats modeling. As I see it this will require
> >>> modifying at least one or both models.
> >>> https://indiewebcamp.com/post-type-discovery#Examples
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
>
>