[Hawkular-dev] Hawkular.org

Tue Jun 14 09:09:40 EDT 2016

On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman <miburman at redhat.com> wrote:

> Consumers is terrible word for any client, as they both consume as well as
> produce the data.

Well that was actually reflecting the current state, we have "things" that
feed data to the server and "things" that consume data from the server. The
client libraries provide an API to feed and consume.

> For example for Heapster, we currently produce the data, however at the
> moment I'm creating a change that will consume the data from HWKMETRICS.
>

Why does it consume data now ?

Thomas

> Integration / clients is far more used and known word, while
> consumer/producer is something more specific and implies a design pattern.
>
>   - Micke
>
> ----- Original Message -----
> From: "Alissa Bonas" <abonas at redhat.com>
> To: "Discussions around Hawkular development" <
> hawkular-dev at lists.jboss.org>
> Sent: Tuesday, June 14, 2016 3:32:16 PM
> Subject: Re: [Hawkular-dev] Hawkular.org
>
>
>
> On Tue, Jun 14, 2016 at 2:46 PM, Thomas Heute < theute at redhat.com > wrote:
>
>
>
>
>
> On Tue, Jun 14, 2016 at 1:24 PM, Alissa Bonas < abonas at redhat.com > wrote:
>
>
>
> 1. I would put REST api as a separate section, and also not in the same
> hierarchy/section as client libraries, because REST is part of the project,
> and clients consume it.
>
> I'm not sure, from a developer perspective it doesn't really matter if
> REST is part of the project (except that you have nothing else to
> download/use), but it should be clear what options, as a developer, you
> have.
> One has the choice between Ruby, Python, Go or plain REST.
>
> At least that was my way of thinking.
>
>
>
>
> 2. Having sections named "clients" and "client libraries" can be confusing.
>
> Agreed.
>
>
>
> Perhaps "integrations" or "applications that consume hawkular" is better
> for "clients"?
>
> I thought of "consumers" for a short name. As we have "feeds" that feed
> data and "consumers" that consumed and display or do something with the
> data. Still not convinced about that name though....
>
> consumers sounds good.
>
>
>
>
>
>
> 3. Is there a section dedicated to community events
> (meetups/conferences/hackaton/summit, etc.) where there are talks about the
> project? Didn't see it in the diagram.
>
> Good point.
> We should probably splash them on the front page + blog.
>
>
>
> 4. Overview can link to quick start imo
>
> Not sure what you mean, after one read the overview he should definitely
> be invited to get started.
>
> my point was that the navigation should be as simple and efficient as
> possible. so if a user reads the overview page, there's no need to go
> to the homepage again in order to go to "get started", but rather navigate
> directly/have an inviting link from overview to get started.
>
>
>
>
>
>
> 5. What should be the difference between quick start and the download
> sections?
>
> Quick start explains how to install the quickest way and get something out
> of the product.
>
> The download section allows to find links of latest and previous releases.
>
> like above, I would also link between quick start and download pages so
> the user will get a convenient flow of "here's how to" and "here's where
> you can download from"
>
>
>
>
>
>
> 6. Ways to contact community? I saw only social links in the footer, but
> what about mailing list/irc,etc.?
>
> That would be in Community>Connect
>
>
>
>
>
>
>
> p.s. I wrote an article couple of years ago on usability of community
> websites, maybe some ideas from there would be helpful as well
> https://opensource.com/business/14/8/open-source-project-front-door
>
>
> I'll have a look, thanks !
>
> Thomas
>
>
>
>
>
>
> thanks,
> Alissa
>
> On Tue, Jun 14, 2016 at 1:25 PM, Thomas Heute < theute at redhat.com > wrote:
>
>
>
> With the recent repackaging effort + the ManageIQ UI, we need to rethink
> hawkular.org .
>
> It's tricky to keep it simple, what to download, for what usecase... And
> at the moment it's getting outdated.
>
> IMO, it should be trivial for end users to figure out:
> - What to download
> - where to download and how to install the server
> - find/browse/download the various options to feed the server with data
> (WF agent, ptrans supported protocoles, ...)
> - find/browse/download options to use/read the data: (ManageIQ, Grafana...)
>
> and for the developers
> - find/browse/download the client libraries (Ruby, Python...)
> - Find client libraries documentation
> - Find examples...
>
> We should probably not separate/fork Hawkular Services from Hawkular
> "community" too much, beside the installation procedure and few things that
> we would mention as only available in the "larger" package. I use the term
> "Hawkular Server" in the mind map for the 2 "flavors".
>
> Please propose improvements to the draft attached that represents the
> website structure. (A square is not necessarily a page, it may be a section
> of a page)
>
> Thomas
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160614/a0bd85c0/attachment-0001.html 