Re: moving forward—with a plan

Hi all,

regarding calls, I share Ruben's analysis about the trade-off between
openness and commitment, and I think that weekly or bi-weekly calls are the
way forward. I can't guarantee that I will be able to attend (although I
would like), but someone from my group definitely will.

regarding mailing list vs. github issues... I agree that an issue-tracking
system may help structure discussions, so maybe we should use github issues
more extensively/systematically. On the other hand, such a system does not
fit all the discussions that need to happen. For example, where would you
publish the minutes of the calls ? This is important if you don't want to
give the impression that the participants to those calls are pulling the
strings behind closed doors :-)
Also, I have some minor concerns about locking the valuable discussions
into a proprietary system, but I could live with that.

best

On Sun, May 22, 2016 at 10:36 PM, Adam Christie <adam.christie@digirati.com>
wrote:

> Hi all,
>
> Just a quick note to say that I'm all in favour of working groups using
> spaces like GitHub actively. It makes things much easier for someone who is
> new to the list to work out what is going on and the history of things.
>
> Definitely interested in something like a bi-weekly community call, I
> think that will have a lot of benefits as well as driving things forward.
>
> +1 for more examples in documentation
>
> Sorry for not giving proper replies to questions before, this is primarily
> due to not having finished building our API yet and making it open source.
> However that is hopefully fewer than a couple of months away.
>
> We chose Hydra as a basis for our API because of its representation in
> JSON-LD which matches the format of data we consume and emit from our API.
> The relation to RDF is a bit opaque to me as an application developer, but
> I understand that it's there - it doesn't form a focus for me though.
>
> Best regards,
>
> Adam.
>
>
> -----Original Message-----
> From: Tomasz Pluskiewicz [mailto:tomasz@t-code.pl]
> Sent: 18 May 2016 21:03
> To: public-hydra@w3.org
> Subject: Re: moving forward—with a plan
>
> Hi Ruben
>
> This a very important email. It is evident that the group has lost
> momentum, yet we are far from the goal still.
>
> TL;DR;
>
> We must encourage more active participation in crafting the specification
> and features. Lengthy email discussions don't cut it.
>
> Long reply:
>
> In my opinion there are three main factors which hinder our progress.
>
> 1. I think that there is a great deficiency abound tooling used to
> maintain and contribute to the community.
>
> I. Call me hip but I find mailing lists old-fashioned. There is a
> repeating problem with HTML vs. plain text and JSON samples keep breaking
> for me. Long threads are a pain, especially when they branch to weakly
> related subjects. I also don't agree that it's easy to search, not to
> mention the horrible online viewer. And instead of actually contributing
> real changes, which would push the specs forward, we end up with endless,
> hard to follow discussions.
>
> II. W3C wiki is usually a dead end, which never gets updated and is hard
> to navigate.
>
> III. Finally, there is GitHub which we don't use enough. The issues there
> are mostly outdated and disconnected from the discussions unless Ruben or
> Markus remember to add a link.
>
> 2. Second issue is simple IMO. We need to address real issues and offer
> concrete, working solutions. Currently the spec is hard to process and
> lacks complete examples. Not to mention tooling, but that will likely come
> when people start to understand and appreciate the benefits of what Hydra
> tries to accomplish.
>
> 3. And so, Hydra needs a clear vision of what it actually does. Markus'
> console is a great showcase but it went out of sync with the specs lately.
> And without detailed examples it's not so easy to understand why and how it
> works...
>
> ----
>
> Like it or not, Hydra must compete with other modern hypermedia solutions,
> eg. Open API Initiative. Just have a look at their GitHub page [1]: 299
> closed issues, 164 closed pull requests, 3600 stars.
> GitHub has many advantages over the current flow. It integrates issues,
> proposed changes and specification/examples' source code.
>
> I think we should take advantage of GitHub's features as one way to
> attract more contributors:
>
> * Move long running discussions to GH issues (better search, actual code
> snippets, easy links between issues and code)
> * Use code comments to discuss the spec and pull requests
> * Maybe move the specification from HTML to markdown and publish with
> GutHub pages (anyone else noticed that the published specification URL is
> down sometimes?)
> * Possibly use raw GitHub URLs + repo tags to track and test-drive past
> and future versions of Hydra.
> * Most people host code on Hydra and so integration between Hydra Core
> repository and implementations' repositories will also be a plus
>
> I would think that with everything (issues/discussions, spec and pull
> requests, wiki and examples) concentrated on GitHub it will be way easier
> for people to discover Hydra, find answers and contribute.
>
> >
> > Our use cases are starting to move at a higher speed now, with
> > different people actively developing different variations of the
> > interface. Such variations only make sense if we can describe to
> > clients what is going on. Unfortunately, the Hydra Core Vocabulary
> > currently cannot keep up. We could interpret this in two ways:
> > either we are moving too fast, or Hydra is moving too slow. Of course,
> > all of us here have done our best to keep things moving. A particular
> > attempt at this is the very long thread about filters. Yet after
> > months of work, and the feeling we are almost there, nothing has
> > materialized.
>
> There is a long way from the mailing list, to agreement, to actually
> writing the spec down.
>
> Also, maybe it is the right moment to consider introducing some kind of
> extensibility to Hydra so that you can develop custom features you need and
> then discuss/contribute them back to Core vocabulary?
>
> >
> > We could see this as a sign we need to resurrect that thread, but I
> > doubt this is what's really needed. What I think we need is a
> > different way of managing the Hydra effort altogether. Perhaps we need
> > weekly, bi-weekly, or monthly calls. Perhaps we need a steering
> > committee or dedicated task force.
>
> I would not like to see Hydra go the way you propose. I fear the such
> cyclical meetings and some kind of task force would actually drive people
> away. This completely loses the openness and gives the impression that
> there is some closed group of dissidents pulling the strings. What we need
> is an open community which will contribute ideas and their needs.
>
> However, a few calls could be good to discuss how we want to execute the
> required changes to actually start moving forward again. From then on I
> would expect calls to be a rare occurrence.
>
> > But I need to see Hydra move at a sustainable pace, with clear
> > milestones, deliverables, and commitment. Otherwise, we'll have no
> > choice but to pursue other paths—and that would be a shame. I'm more
> > than willing to invest time in Hydra, but then I need to be able to
> > see where we are going, and when.
>
> What if Hydra became more agile: deliver often and fail fast. Currently it
> would seem that we're hardly delivering at all. For me deliverables for any
> single feature should be a clear spec and examples of using that feature.
>
> Regards,
> Tom
>
> [1]: https://github.com/OAI/OpenAPI-Specification
>
>
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This private and confidential e-mail has been sent
> to you by Digirati Limited. This is a UK limited company, registration
> number SC235053 The information in this e-mail (which includes any files
> transmitted with it) is confidential and may also be legally privileged. It
> is intended for the addressee only. Access to this e-mail by anyone else is
> unauthorized. It is not to be relied upon by any person other than the
> addressee except with our prior written approval. If no such approval is
> given, we will not accept any liability (in negligence or otherwise)
> arising from any third party acting, or refraining from acting, on such
> information. Unauthorized recipients are required to maintain
> confidentiality. If you have received this e-mail in error please notify
> the originator immediately, destroy any copies and delete it from your
> computer system. The unauthorized use, dissemination, forwarding, printing
> or copying of this e-mail is prohibited.
>
> Thank you.
>
> Digirati Limited, Unit G 4, The Hub, 70 Pacific Quay, Glasgow G51 1EA | 31
> Clerkenwell Close, London EC1R 0AU
> Telephone +44 (0)845 643 4370: website: www.digirati.com
> <>
>
>
>