[aerogear-dev] [feedhenry-dev] Upstream Community Documentation

Wed Nov 29 10:08:11 EST 2017

Inline

On 11/29/2017 02:14 PM, Summers Pittman wrote:
>
>
> On Wed, Nov 22, 2017 at 10:02 AM, Wojciech Trocki <wtrocki at redhat.com 
> <mailto:wtrocki at redhat.com>> wrote:
>
>     Thanks for raising that question - I think it's really important
>     to talk about it.
>     I think we had the similar conversation 6 months ago when
>     kickstarting RainCatcher docs.
>
>     Personally I think is essential for every project to have his own
>     landing sub page (with documentation,demo video etc.) that can be
>     accessed easily from feedhenry, aerogear main web pages.
>
Project?  sync, push, raincatcher, digger - after that I'm not sure, is 
each sdk a project or not?
Do the users care what we consider to be a project? I'm thinking for 
mobile.next, the end user might start by considering MCP, but then later 
think about sync, then later think about the ios sdk.

I thinkthis <https://en.wikipedia.org/wiki/Lumpers_and_splitters>needs 
further exploration, but Raincatcher is a good example of things working 
well.

>     In RainCatcher we went even further and created separate web page
>     (that is linked in feedhenry.org <http://feedhenry.org>).
>     This works pretty well as documentation, getting started etc. is
>     exposed directly on the main page.
>
Yea, I like that there's a feature associated with a set of repos, and 
one doc repo to tie the functionality together. We could set the 
homepage for all the associated repos to the published version of the 
doc repo to tie them together.
>
>
>     I think that feedhenry.org <http://feedhenry.org> has really good
>     layout itself when listing all projects. We could just provide
>     less information so people looking for something specific will not
>     need to scroll too much.
>     Spring (any many other aggregating communities) do the same. For
>     example: https://spring.io/docs/reference
>     <https://spring.io/docs/reference>
>
>     We can apply similar list to aerogear website - however I'm not
>     aware of the impact or challenges in that area)
>
Here's the big one:

Would it help to redirect aerogear.org to feedhenry.org and host 
everything there? I think that's been hinted at, but not asked 
explicitly up to now. For me the advantages are:

* one website is easier than two (process, tooling, communications, etc)
* addition is easier than subtraction, easier to add digger/push to 
feedhenry.org, than to extract dead material from aerogear
* not having to deal with jekyll/plugins ;)

Paul

>
>     On Wed, Nov 22, 2017 at 1:59 PM, Paul Wright <pwright at redhat.com
>     <mailto:pwright at redhat.com>> wrote:
>
>         Hi AeroGear, FeedHenry
>
>         As part of a review of Digger (Build Farm) docs,  I created a
>         PR <https://github.com/aerogear/aerogear.org/pull/687> to
>         attempt to improve user navigation of:
>
>         https://aerogear.org/
>
>         Feedback on that PR raised the question of general navigation
>         of this web site:
>
>         * What should be in the Getting Started menu to help me get
>         started with digger? (I think digger is more than a code
>         snippet or library)
>
>         * If I'm interested in digger, should I expect any digger info
>         under module or platform menu items?
>
>         * I sometimes navigate to a page, but can't remember how I
>         navigated to it, then cannot find the info again.
>
>         These issues can be resolved, but will require a lot of
>         effort, but another question is:
>
>         * Will it provide us a platform to build the community we want?
>
>         The web site looks great, and I learn a lot from browsing it
>         (eg I didn't know about https://aerogear.org/sync/ until
>         today), but I wonder if it is doing the job we want it to do?
>         and how do we keep it up-to-date?
>         (https://aerogear.org/docs/planning/
>         <https://aerogear.org/docs/planning/>)
>
>         Meanwhile over at:
>
>         http://feedhenry.org/docs/
>
>         Not much there at the moment, but it will be the location for
>         mobile.next doc
>
>         * Do we want users switching from MCP doc on feedhenry.org
>         <http://feedhenry.org> over to digger doc on aerogear.org
>         <http://aerogear.org> and back again for some fh.sync doc?
>
>         These are difficult and challenging questions, I don't expect
>         them to be easy to resolve and I'm happy to agree with
>         whatever the communities decide to do. All this mail hopes to
>         do is to raise the question of
>
>         * How do we communicate the "mobile.next" (i.e. feedhenry mcp
>         and aerogear digger) message as cleanly as possible?
>
>         (The real challenge occurs after that, convincing them to
>         adopt mobile.next, but users will never adopt if they can't
>         find answers  they hit the first stumbling block)
>
>         thanks,
>
>         Paul
>
>
>         _______________________________________________
>         feedhenry-dev mailing list
>         feedhenry-dev at redhat.com <mailto:feedhenry-dev at redhat.com>
>         https://www.redhat.com/mailman/listinfo/feedhenry-dev
>         <https://www.redhat.com/mailman/listinfo/feedhenry-dev>
>
>
>
> Bumping this a bit.
>
> Over the summer the community team put together a backlog of items to 
> update the feedhenry sdk page, automate some documentation and 
> blogging aggregation, and begin to plan on how we would keep docs, 
> demos, etc up to date from a community perspective.
>
> https://issues.jboss.org/secure/PortfolioPlanView.jspa?id=28&sid=30#backlog 
> (if that isn't working let me know).
>
> While we didn't look at the aerogear community as we were focusing on 
> "feedhenry" it may be a good opportunity to spin the team back up and 
> bring Aerogear into its fold.  This will mean either maintaining two 
> websites and brands or combining them into a single landing page for 
> docs and community to feed into the mobile upstream.
>
> MCP plays an important role in this because it is pulling together a 
> lot of the strings from AeroGear, Wildfly, node.js, jboss, feedhenry, 
> etc into a single "launchpad".
>
>
>
>
>
>     -- 
>
>     WOJCIECH TROCKI
>
>     Red Hat Mobile <https://www.redhat.com/>
>
>     IM: wtrocki
>
>     <https://red.ht/sig>
>
>
>     _______________________________________________
>     feedhenry-dev mailing list
>     feedhenry-dev at redhat.com <mailto:feedhenry-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/feedhenry-dev
>     <https://www.redhat.com/mailman/listinfo/feedhenry-dev>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20171129/64cecbe4/attachment.html 