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.

Can anyone explain how a call can improve anything here? From my experience, 
the more participants and the longer the call, nothing comes out of such a 
meeting.

>regarding mailing list vs. github issues... I agree that an issue-tracking 
>system may help structure discussions
I agree as well that any kind of issue tracker would organize things better. 
If it is going to be developed by more than one driving force (currently 
Markus and Ruben), it's definitely the way to go.

Best

Karol

From: Pierre-Antoine Champin
Sent: Monday, May 23, 2016 10:29 AM
To: public-hydra@w3.org
Subject: 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
<>

Received on Monday, 23 May 2016 17:44:36 UTC