- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Mon, 17 Dec 2018 16:34:26 +0100
- To: Karol Szczepański <karol.szczepanski@gmail.com>
- Cc: Hydra <public-hydra@w3.org>
- Message-Id: <84E63A54-1BE6-4BA8-A253-55E035EED4D6@t-code.pl>
Hello again. Sorry for quick succession of emails. I realized I added some links but not to the Slack I mentioned. Here’s the self-invite page: http://slack.httpapis.com <http://slack.httpapis.com/> See you there Tom > On 17 Dec 2018, at 16:14, Tomasz Pluskiewicz <tomasz@t-code.pl> wrote: > > Congratulations Karol for the promotion! > > As a general note let me share what I heard from Darrel Miller last week, when asked about the Open API spec or actually its early Swagger days. He said that in the beginning no one cared about the spec. The winning factor was tooling. This is just as true with most IT tech. We should focus our efforts on tools. Both code that the Hydra CG builds as well as third party software. > > We should focus on that mostly: working software showing “real life” examples. Or as close as we can get. I personally often felt that Hydra discussions were too detached from reality. And the spec itself should be open and extensible. So, first, we need to ground the spec in really goals and API may want to achieve and then refactor the initial design so that the structure is adaptable to unanticipated scenarios. > > Speaking of implementation, I included Kevin Dunglas who has done integrating Hydra with PHP’s Symfony [1] framework and API Platform [2]. I spoke to Kevin and he promised to shared their experience and issues they had with Hydra back with the community. We’re counting on you Kevin. GitHub is waiting. We are waiting! > > I would actually encourage looking up to Open API Initiative for inspiration on all aspects of how an API spec community can be ran. Given the success it’s had over the years. > > Finally, to move things forward I’d like to propose to already schedule a next Hydra CG call for early January. Keeping it Monday, the next slot would fall on January 7th. This should give us some time to regroup, collect our thoughts on the future of Hydra and start 2019 with a renewed strength. > > More comments inline. > > Thank you for reading, > Tom > > [1]: https://symfony.com <https://symfony.com/> > [2]: https://api-platform.com <https://api-platform.com/> > >> On 16 Dec 2018, at 20:04, Karol Szczepański <karol.szczepanski@gmail.com <mailto:karol.szczepanski@gmail.com>> wrote: >> >> Dear all >> >> I've started my journey with this community about three years ago >> strongly believing in the hydra's approach on modern APIs. >> I couldn't stand seeing all of the Markus' and the community efforts >> wasted, I've decided to give it a try and push the whole stuff. > > Very much so. Hydra has too much unique potential to let it go waste! > >> >> My time is somehow limited (it always was) and while I'll be formally >> a chair - a single point of contact, I'd hate to become a single point >> of failure. >> That's why I've asked Tomasz (another active member of this community) >> for help with this mission (and he agreed). > > I will be honoured to help you out with this task. I have not been active enough over the last year or so but this will hopefully change in the nearest future. Long term plans in my current job at Zazuko [3] are to use Hydra for our APIs. This means that I will have more incentive and time to work on the specification and related coding. > > [3]: https://github.com/zazuko <https://github.com/zazuko> >> >> To start with, we'd like to do some cleanup on GitHub's issues list >> first (there are some unresolved issues from 2013) so we can focus on >> the important matters. >> Some are probably already obsolete, but some may be still valid and in >> need of an urgent attention. > > Yes, I concur. I think we should fairly aggressively eliminate the ancient backlog. Some issues will likely simply be closed. Some others are half-complete, and some are technically done but not written down in the spec. Especially those last should be taken care of so that we can do any kinds of progress, experiment with the design and improve in next iteration. > >> >> We'd also like to move discussions to GitHub rather than to mailing >> list - this way we could have all issues, spec and Heracles.ts PR's >> linked altogether. > > I agree however this is a double edged sword. To keep the community swift we’ll have to commit to responding timely on the mailing list, GitHub and other channels. > > Speaking of channels. I proposed some time in the past to also make use of instant messaging platforms. The best options seem Gitter, which I don’t particularly like, or Slack. A dedicated slack could be an overkill so I'd propose to reuse an existing community. Personally I’m member of HTTP APIs slack, which has 500 moderately active members, high quality discussions and, most importantly, Hydra and JSON-LD are a recurring subject. The Hydra channel gets an occasional question too but that he’s been under the radar of Hydra CG. I say we take advantage of an additional platform to promote a short feedback loop where emails or GitHub may be too much. Might as well integrate the #Hydra channel with GitHub too, so that issue updates are notified back to a wider audience. > >> This also means more of a 'fail-fast' approach with spec changes. With >> Heracles.ts we can experiment with the spec in a more agile way. >> Maybe that approach will bring some fresh air and features that could >> cover demands put against the hydra itself. >> >> As for the spec - I personally have a couple of must-have features: >> - request's shape - something that would bind altogether body, URI >> template and possibly headers; these are somehow disconnected now >> - API documentation - this part is heavily underdeveloped; I tried to >> create a use case for that and I've failed; while hypermedia controls >> are quite well defined and carry a great value that makes hydra >> superior to other solutions, but we also need features those other >> solutions already provide > > I wouldn’t be surprised if your concerns already have some related issue(s). Let’s check that first and if not then let’s move forward with PRs. > >> >> Anyway - all of this won't happen without you - the community. >> Features won't appear out of nowhere, reviews won't be performed >> without your attention. >> I hope we'll all be able to move forward with our ideas regarding hydra > > +1, although until we regain some traction with the community, I shall assume that most work will fall on the maintainer(s). > >> >> Kind regards, >> Karol >> >> PS. While I won't 'wait or block any decision' on you Markus, I'm >> happy to see you lurking around :) >> >> niedz., 16 gru 2018 o 17:00 Markus Lanthaler >> <markus.lanthaler@gmx.net <mailto:markus.lanthaler@gmx.net>> napisał(a): >>> >>> Hi folks, >>> >>> I should have done this quite a while ago, but with the recent discussions >>> about Hydra's state it's finally time to make room for new leadership in >>> this community. I'm stepping down from any leadership role, real or >>> perceived, I have in this group. It's been a very long time since I've had >>> enough spare cycles to meaningfully lead the development and I apologize for >>> not having done this sooner. >>> >>> I had a chat with Karol recently and given that he's interested in pushing >>> Hydra further, I decided to make him a chair of this W3C community group. >>> I'll probably not be able to resist the temptation to lurk around and >>> observe in which direction you are going to drive Hydra - I'll refrain from >>> stepping in though. That also means, that you should never ever wait or >>> block any decision on me. It is in your hands now. >>> >>> I hope that not only Karol, but also a few others in this community will >>> step forward and take up the great work that this community has done over >>> the past several years. >>> >>> >>> All the best, >>> Markus >>> >>> >>> -- >>> Markus Lanthaler >>> @markuslanthaler >>> >>> >>> >> >
Received on Monday, 17 December 2018 15:35:40 UTC