Re: Stepping down

Hello Lorenzo

Please make sure you join the call tomorrow so that we can discuss organisational matters first. They may be more important than moving forward with the spec GitHub issues at this point.

I agree with your sentiment that Hydra is currently a bit fragmented, even though the number of active parties is somewhat limited. In addition to the personal work anyone out there may be conducting, I mostly speak about Hydra ecosystem (https://github.com/HTTP-APIs <https://github.com/HTTP-APIs>). Even though it is not officially part of the Community Group, it has been recognised as such. I am referring to Sebasien Lambla’s Slack message in which he makes assumptions that the two are part of a larger whole, which is not currently the case. 
I strongly believe that the immediate step should be to unify the efforts to improve visibility an coordination. 

Now, speaking of the standard and specification itself, let me paraphrase what I heard from Darrell Miller speaking about Open API (the Swagger). He told me that “no one cared about the spec”. Like you say, the important factor guaranteeing its success was indeed the tooling. In that regard I admire your efforts and they should continue. I have been working on some software around Hydra for a while now too. What we need IMO is to showcase these tools, battle test them and use the knowledge we gain from said tests to improve the specification in a tight feedback loop.

For me that is probably the biggest challenge. The current efforts have often been hampered by too many people trying to achieve disparate goal. Discussion on the mailing list often ended in an impasse. Finally, even “resolved” discussions did not end up written down in the spec itself, which further contributes to the confusion about Hydra. This last problem is consequently the most pressing issue in my opinion.

To sum up, here’s my perceived, high-level action plan:

1. Unify the communities by improving communication
2. Update the spec so that it accurately represents the current feature set
3. Conduct further work on working code and realistic examples, requirements and goals. We should avoid too theoretical discussions
4. Prefer agility over perfection 
5. Aggressively increase larger presence. Conferences are a big effort but we could also do Twitter, blog posts and commit monitoring to instant messaging platform such as Slacks or Gitter. I think that is something that a larger community expects

Best,
Tom

> On 6 Jan 2019, at 14:39, Lorenzo Moriondo <tunedconsulting@gmail.com> wrote:
> 
> Hi,
> 
> Sure. I write here as a spokeperson of the developing team we have build in these years with GSOC to present some general guidelines-related questions (if this is TL;DR for somebody, you can jump directly to the "Questions" paragraphs at the end).
> 
> I believe the wish for everybody is to move on the draft to be successfully approved in the years to come. To make this possible, one of the needed requirement is for a relevant global community of developers to back Hydra usage as current practice in different (enterprise or Open Sources) codebases (see what happened with GraphQL or OpenAPI, even with different governance models and ways of attracting interest from developers). In one of previous discussions (State of Hydra thread), I tried to outline what is the scenario we may want to reach to  give Hydra the critical mass to become a standard, I briefly repeat here for convenience:
> 
> """
> The draft can become a standard only with wide industry adoption. I think that we are talking of a perspective of at least ~5-10 years, if we build the right packages for the most popular languages in the next few years. I suppose that the target is making Hydra become a standard for ~10-20% of the installations around. Considering the current adoption and the public tools available, we are still in an early phase, that is not so bad considering the time span that Hydra should target. There are two possible routes, both worthy: make vocabulary developers add Hydra to their spectrum of tools; but also facilitate at most the use of Hydra for newly published datasets that can link to existing ones. Hydra Ecosystem focuses on this second option.
> """
> 
> This requires a long-term effort in terms of community-building. That is why I asked Markus in 2017 if he thought was a good idea to participate in Google Summer Of Code and we started this adventure that has been growing consistently in the last two years (now we are looking ahead to apply for the third year; we started with 2 students and we now have 20+ contributors, for the first time this year we presented at a major event; developers that hardly would have ever get in touch with Hydra, now know the technology).
> From a developer point of view Hydra is an high peak to reach in terms of skills required to create a vocabulary and to deploy a client-server infrastructure. Thanks to GSOC we can let tenths of developers to acquire the skills to use Hydra in the future; equally important is for the specs to test themselves in the wild, with real-world usage patterns in cloud environments. We believe that this is of great benefit for Linked Data and to bring the values of W3C to younger generations.
> 
> Mentors can keep up with this responsibility, if we decide that this activity has to be independent from the activity of the CG; instead if you think that the effort has to be guided by the CG (because in our opinion is strictly entangled with the life-cycle of the standard), we have to establish a minimal governance model to make Hydra recognizable as a player in the Open Source development landscape. This implies a strategy in acquiring sources of backing (like GSOC or any other institution that support OS or the usage of Hydra; having a list of peers would be a good starting point) to ensure a steady growth. 
> 
> ***Questions***
> 
> At the moment we have had distinct entities (the specs designers and the GSOC initiative plus everybody else working on their own projects); GSOC mentors can be the transmission chain to beginners. What we see from our point of view, we possibly need somehow to engineer a transition from (or a proper spin-off from) Community Group to Open Source organisation in the next years to make possible delivering the draft to a standard. Is the intention of the CG to participate/lead somehow in this kind of enterprise or this is left completely to the initiative of groups of singles? I admit my ignorance about W3C standards life-cycles so to ask: how can the draft practically move on without a proper OS organisation? How can we gather consensus to become a standard otherwise?
> 
> What is needed to re-ensure contributors and adopters is to clarify objectives and conduct, and a timeline. Engineering the specs is a fundamental component but we need some other components (like the implementation side that implies facilitating adoption and  recognition among peers, presence at events, etc) also in place to be a sound alternative as an hypermedia REST documentation framework and reach approval. Is all of this or part of it in the agenda?
> 
> Best,
> 
> On Sat, 5 Jan 2019 at 20:43, Karol Szczepański <karol.szczepanski@gmail.com <mailto:karol.szczepanski@gmail.com>> wrote:
> Lorenzo
> 
> --Please Karol let us know in the next weeks the role you have in mind
> for the effort
> --we are keeping up with Google Summer Of Code for creating a strong
> global community for
> --Hydra API developers: objectives, timeline, organisational structure
> 
> Could you please elaborate more? In general I'm only aware of GSOC
> existance, but I didn't participate in any way.
> While I have some vision and plan for Hydra itself, I didn't think
> about these for GSOC
> 
> Karol
> 
> sob., 5 sty 2019 o 14:40 Lorenzo Moriondo <tunedconsulting@gmail.com <mailto:tunedconsulting@gmail.com>>
> napisał(a):
> >
> > Thanks truly Markus for all your time dedicated in these years and your inputs and ideas as Chairman!
> >
> > Please Karol let us know in the next weeks the role you have in mind for the effort we are keeping up with Google Summer Of Code for creating a strong global community for Hydra API developers: objectives, timeline, organisational structure. This is relevant as the 2019 GSOC Organisations are meant to apply before the end of January. If you need it we can provide a brief report of the activities carried on since 2017.
> >
> > Best,
> >
> > On Fri, 4 Jan 2019 at 23:42, Ruben Verborgh (UGent-imec) <Ruben.Verborgh@ugent.be <mailto:Ruben.Verborgh@ugent.be>> wrote:
> >>
> >> Dear Markus,
> >>
> >> Thanks for all you’ve done. It’s been great.
> >> You will be missed.
> >>
> >> The Hydra ideas are still great and necessary for today’s Web.
> >> Let’s make them happen.
> >>
> >> Best,
> >>
> >> Ruben
> >
> >
> >
> > --
> > ¤ acM ¤
> > Lorenzo
> > Moriondo
> > @lorenzogotuned
> > https://www.linkedin.com/in/lorenzomoriondo <https://www.linkedin.com/in/lorenzomoriondo>
> > https://github.com/Mec-iS <https://github.com/Mec-iS>
> 
> 
> -- 
> ¤ acM ¤
> Lorenzo
> Moriondo
> @lorenzogotuned
> https://www.linkedin.com/in/lorenzomoriondo <https://www.linkedin.com/in/lorenzomoriondo>
> https://github.com/Mec-iS <https://github.com/Mec-iS>