Upstream Community Documentation

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Upstream Community Documentation

pwright

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

Wojciech Trocki
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.
In RainCatcher we went even further and created separate web page (that is linked in feedhenry.org). 
This works pretty well as documentation, getting started etc. is exposed directly on the main page.

I think that 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

We can apply similar list to aerogear website - however I'm not aware of the impact or challenges in that area)

On Wed, Nov 22, 2017 at 1:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Upstream Community Documentation

Matthias Wessendorf-2
In reply to this post by pwright
Hi Paul,

lot's of content on the AeroGear website is out of date, due to lack of work in the past two years (see the planing page).

Note: the sync was a prototype, for real-time sync; based on different algorithms and papers in that area, but never went really anywere... 
I guess it's dead now.

Over the past two years we did work a bit on the AeroGear Push server, and their libraries (e.g. mobile client-side lib and server-side integrations for node/java).

Regarding Digger - it's a standalone project, under the aerogear realm - like push.  Both bits can be used completely independent. 


I think some content (e.g. sync) needs to be removed (while we can still keep the repos), but we should be perhaps focusing on AeroGear UPS and digger, for community offerings.

ag.org/push (like is)
ag.org/digger (with backgrounds motivations, Laura's videos etc)


Regarding feedhenry / mcp , just one comment: it does integrate w/ AG features, such as push or digger, and will IMO offer the integration parts (e.g. APBs etc)


-Matthias


On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Upstream Community Documentation

Ali Ok
Hello,

FYI, once I started this epic to improve and clean up AeroGear.org website: https://issues.jboss.org/browse/AEROGEAR-1760

If we would like to do it, we need to find out a group that takes ownership of the clean up. AeroGear people are now more spread than before.

Cheers

On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi Paul,

lot's of content on the AeroGear website is out of date, due to lack of work in the past two years (see the planing page).

Note: the sync was a prototype, for real-time sync; based on different algorithms and papers in that area, but never went really anywere... 
I guess it's dead now.

Over the past two years we did work a bit on the AeroGear Push server, and their libraries (e.g. mobile client-side lib and server-side integrations for node/java).

Regarding Digger - it's a standalone project, under the aerogear realm - like push.  Both bits can be used completely independent. 


I think some content (e.g. sync) needs to be removed (while we can still keep the repos), but we should be perhaps focusing on AeroGear UPS and digger, for community offerings.

ag.org/push (like is)
ag.org/digger (with backgrounds motivations, Laura's videos etc)


Regarding feedhenry / mcp , just one comment: it does integrate w/ AG features, such as push or digger, and will IMO offer the integration parts (e.g. APBs etc)


-Matthias


On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Upstream Community Documentation

John Frizelle
Hi All,

I would like to get people's thoughts on the cost / benefit of continuing to maintain both the feedhenry and aerogear communities (mailing lists, IRC channels, web sites etc...). There seems to be a lot of cross over between the two (the are both mobile focused communities backed primarily by Red Hat) and I struggle to see what benefit we, or our community members, get from having our work spread across these two communities...

From my perspective, I would rather see one healthy, vibrant community that we can all get behind instead of the current fractured status where it is unclear what lives where and why.

Just my 2 cents...

Cheers,
John.


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 23 November 2017 at 13:09, Ali Ok <[hidden email]> wrote:
Hello,

FYI, once I started this epic to improve and clean up AeroGear.org website: https://issues.jboss.org/browse/AEROGEAR-1760

If we would like to do it, we need to find out a group that takes ownership of the clean up. AeroGear people are now more spread than before.

Cheers

On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi Paul,

lot's of content on the AeroGear website is out of date, due to lack of work in the past two years (see the planing page).

Note: the sync was a prototype, for real-time sync; based on different algorithms and papers in that area, but never went really anywere... 
I guess it's dead now.

Over the past two years we did work a bit on the AeroGear Push server, and their libraries (e.g. mobile client-side lib and server-side integrations for node/java).

Regarding Digger - it's a standalone project, under the aerogear realm - like push.  Both bits can be used completely independent. 


I think some content (e.g. sync) needs to be removed (while we can still keep the repos), but we should be perhaps focusing on AeroGear UPS and digger, for community offerings.

ag.org/push (like is)
ag.org/digger (with backgrounds motivations, Laura's videos etc)


Regarding feedhenry / mcp , just one comment: it does integrate w/ AG features, such as push or digger, and will IMO offer the integration parts (e.g. APBs etc)


-Matthias


On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Upstream Community Documentation

Matthias Wessendorf-2
I personally don't have a problem with moving them together (e.g. move the UPS to FeedHenry). The name aerogear for most people was always attached to the Push Server. Perhaps we call the UPS -> FH AeroGear Push :) ?

But the rest, especially the client modular libs,.. yeah - I don't have an opinion where they should live. 

On Thu, Nov 23, 2017 at 2:23 PM, John Frizelle <[hidden email]> wrote:
Hi All,

I would like to get people's thoughts on the cost / benefit of continuing to maintain both the feedhenry and aerogear communities (mailing lists, IRC channels, web sites etc...). There seems to be a lot of cross over between the two (the are both mobile focused communities backed primarily by Red Hat) and I struggle to see what benefit we, or our community members, get from having our work spread across these two communities...

From my perspective, I would rather see one healthy, vibrant community that we can all get behind instead of the current fractured status where it is unclear what lives where and why.

Just my 2 cents...

Cheers,
John.


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 23 November 2017 at 13:09, Ali Ok <[hidden email]> wrote:
Hello,

FYI, once I started this epic to improve and clean up AeroGear.org website: https://issues.jboss.org/browse/AEROGEAR-1760

If we would like to do it, we need to find out a group that takes ownership of the clean up. AeroGear people are now more spread than before.

Cheers

On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi Paul,

lot's of content on the AeroGear website is out of date, due to lack of work in the past two years (see the planing page).

Note: the sync was a prototype, for real-time sync; based on different algorithms and papers in that area, but never went really anywere... 
I guess it's dead now.

Over the past two years we did work a bit on the AeroGear Push server, and their libraries (e.g. mobile client-side lib and server-side integrations for node/java).

Regarding Digger - it's a standalone project, under the aerogear realm - like push.  Both bits can be used completely independent. 


I think some content (e.g. sync) needs to be removed (while we can still keep the repos), but we should be perhaps focusing on AeroGear UPS and digger, for community offerings.

ag.org/push (like is)
ag.org/digger (with backgrounds motivations, Laura's videos etc)


Regarding feedhenry / mcp , just one comment: it does integrate w/ AG features, such as push or digger, and will IMO offer the integration parts (e.g. APBs etc)


-Matthias


On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev





--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Upstream Community Documentation

Wojciech Trocki
I would rather see one healthy, vibrant community that we can all get behind instead of the current fractured status where it is unclear what lives where and why.

+1. Aerohenry ;) IMHO Best to have single website address (it can even have 2 communities, project labels etc) for all work we do. 
MCP will be the common element that will join all community projects together so it's make sense to aggregate them in one place.
It may also help with all documentation efforts. Lots of people already maintaining projects for both communities. 

On Thu, Nov 23, 2017 at 1:39 PM, Matthias Wessendorf <[hidden email]> wrote:
I personally don't have a problem with moving them together (e.g. move the UPS to FeedHenry). The name aerogear for most people was always attached to the Push Server. Perhaps we call the UPS -> FH AeroGear Push :) ?

But the rest, especially the client modular libs,.. yeah - I don't have an opinion where they should live. 

On Thu, Nov 23, 2017 at 2:23 PM, John Frizelle <[hidden email]> wrote:
Hi All,

I would like to get people's thoughts on the cost / benefit of continuing to maintain both the feedhenry and aerogear communities (mailing lists, IRC channels, web sites etc...). There seems to be a lot of cross over between the two (the are both mobile focused communities backed primarily by Red Hat) and I struggle to see what benefit we, or our community members, get from having our work spread across these two communities...

From my perspective, I would rather see one healthy, vibrant community that we can all get behind instead of the current fractured status where it is unclear what lives where and why.

Just my 2 cents...

Cheers,
John.


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 23 November 2017 at 13:09, Ali Ok <[hidden email]> wrote:
Hello,

FYI, once I started this epic to improve and clean up AeroGear.org website: https://issues.jboss.org/browse/AEROGEAR-1760

If we would like to do it, we need to find out a group that takes ownership of the clean up. AeroGear people are now more spread than before.

Cheers

On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi Paul,

lot's of content on the AeroGear website is out of date, due to lack of work in the past two years (see the planing page).

Note: the sync was a prototype, for real-time sync; based on different algorithms and papers in that area, but never went really anywere... 
I guess it's dead now.

Over the past two years we did work a bit on the AeroGear Push server, and their libraries (e.g. mobile client-side lib and server-side integrations for node/java).

Regarding Digger - it's a standalone project, under the aerogear realm - like push.  Both bits can be used completely independent. 


I think some content (e.g. sync) needs to be removed (while we can still keep the repos), but we should be perhaps focusing on AeroGear UPS and digger, for community offerings.

ag.org/push (like is)
ag.org/digger (with backgrounds motivations, Laura's videos etc)


Regarding feedhenry / mcp , just one comment: it does integrate w/ AG features, such as push or digger, and will IMO offer the integration parts (e.g. APBs etc)


-Matthias


On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev





--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Upstream Community Documentation

Wei Li
In reply to this post by John Frizelle
+1. Maintaining 2 communities with similar objectives are just too confusing to a lot of people. I would like to see them merged as well. 

On Thu, Nov 23, 2017 at 1:23 PM, John Frizelle <[hidden email]> wrote:
Hi All,

I would like to get people's thoughts on the cost / benefit of continuing to maintain both the feedhenry and aerogear communities (mailing lists, IRC channels, web sites etc...). There seems to be a lot of cross over between the two (the are both mobile focused communities backed primarily by Red Hat) and I struggle to see what benefit we, or our community members, get from having our work spread across these two communities...

From my perspective, I would rather see one healthy, vibrant community that we can all get behind instead of the current fractured status where it is unclear what lives where and why.

Just my 2 cents...

Cheers,
John.


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 23 November 2017 at 13:09, Ali Ok <[hidden email]> wrote:
Hello,

FYI, once I started this epic to improve and clean up AeroGear.org website: https://issues.jboss.org/browse/AEROGEAR-1760

If we would like to do it, we need to find out a group that takes ownership of the clean up. AeroGear people are now more spread than before.

Cheers

On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi Paul,

lot's of content on the AeroGear website is out of date, due to lack of work in the past two years (see the planing page).

Note: the sync was a prototype, for real-time sync; based on different algorithms and papers in that area, but never went really anywere... 
I guess it's dead now.

Over the past two years we did work a bit on the AeroGear Push server, and their libraries (e.g. mobile client-side lib and server-side integrations for node/java).

Regarding Digger - it's a standalone project, under the aerogear realm - like push.  Both bits can be used completely independent. 


I think some content (e.g. sync) needs to be removed (while we can still keep the repos), but we should be perhaps focusing on AeroGear UPS and digger, for community offerings.

ag.org/push (like is)
ag.org/digger (with backgrounds motivations, Laura's videos etc)


Regarding feedhenry / mcp , just one comment: it does integrate w/ AG features, such as push or digger, and will IMO offer the integration parts (e.g. APBs etc)


-Matthias


On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Upstream Community Documentation

Laura Fitzgerald
+1 on merging. From my experience having multiple locations where we are documenting the same project has created some unnecessary difficulties in terms of maintaining/managing documentation. 
Also Paul and John raised some valid points here in terms of building community/engagement in use of the product. It's never a fun experience when the documentation on a project is not good and it doesn't give a good impression to start.

On Mon, Nov 27, 2017 at 12:17 PM, Wojciech Trocki <[hidden email]> wrote:

---------- Forwarded message ----------
From: Wei Li <[hidden email]>
Date: Thu, Nov 23, 2017 at 2:46 PM
Subject: Re: [feedhenry-dev] [aerogear-dev] Upstream Community Documentation
To: John Frizelle <[hidden email]>
Cc: AeroGear Developer Mailing List <[hidden email]>, Matthias Wessendorf <[hidden email]>, [hidden email]


+1. Maintaining 2 communities with similar objectives are just too confusing to a lot of people. I would like to see them merged as well. 

On Thu, Nov 23, 2017 at 1:23 PM, John Frizelle <[hidden email]> wrote:
Hi All,

I would like to get people's thoughts on the cost / benefit of continuing to maintain both the feedhenry and aerogear communities (mailing lists, IRC channels, web sites etc...). There seems to be a lot of cross over between the two (the are both mobile focused communities backed primarily by Red Hat) and I struggle to see what benefit we, or our community members, get from having our work spread across these two communities...

From my perspective, I would rather see one healthy, vibrant community that we can all get behind instead of the current fractured status where it is unclear what lives where and why.

Just my 2 cents...

Cheers,
John.


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 23 November 2017 at 13:09, Ali Ok <[hidden email]> wrote:
Hello,

FYI, once I started this epic to improve and clean up AeroGear.org website: https://issues.jboss.org/browse/AEROGEAR-1760

If we would like to do it, we need to find out a group that takes ownership of the clean up. AeroGear people are now more spread than before.

Cheers

On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi Paul,

lot's of content on the AeroGear website is out of date, due to lack of work in the past two years (see the planing page).

Note: the sync was a prototype, for real-time sync; based on different algorithms and papers in that area, but never went really anywere... 
I guess it's dead now.

Over the past two years we did work a bit on the AeroGear Push server, and their libraries (e.g. mobile client-side lib and server-side integrations for node/java).

Regarding Digger - it's a standalone project, under the aerogear realm - like push.  Both bits can be used completely independent. 


I think some content (e.g. sync) needs to be removed (while we can still keep the repos), but we should be perhaps focusing on AeroGear UPS and digger, for community offerings.

ag.org/push (like is)
ag.org/digger (with backgrounds motivations, Laura's videos etc)


Regarding feedhenry / mcp , just one comment: it does integrate w/ AG features, such as push or digger, and will IMO offer the integration parts (e.g. APBs etc)


-Matthias


On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki




--

LAURA FITZGERALD

Red Hat Mobile

Communications House, Cork Road

Waterford City, Ireland X91NY33

[hidden email]    IM: lfitzgerald



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

supittma
Administrator
In reply to this post by Wojciech Trocki


On Wed, Nov 22, 2017 at 10:02 AM, Wojciech Trocki <[hidden email]> 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.
In RainCatcher we went even further and created separate web page (that is linked in feedhenry.org). 
This works pretty well as documentation, getting started etc. is exposed directly on the main page.

I think that 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

We can apply similar list to aerogear website - however I'm not aware of the impact or challenges in that area)

On Wed, Nov 22, 2017 at 1:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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
[hidden email]
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.


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

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

Ali Ok
Hello,

We were talking about this in our team and wanted to give some feedback as we (RHMAP core team) are the ones who perhaps interact with AeroGear and FeedHenry communities/organizations more often than other people.

Wojciech, Paolo and their team has a spent a very good time on thinking about how to improve FeedHenry community and build/expand RainCatcher community.

I think moving things to FeedHenry and calling UPS "FH AG Push" sounds good. 

I won't go and do a full assessment of both communities/organizations but if we're doing this, we should definitely move these things from AeroGear to FeedHenry side and make sure they don't break in the future at least the current AeroGear things where things are working nicely:
* Stable processes (release, JIRA workflow, etc.)
* Open source first mentality (100% community releases, etc.)
* Somewhat active non Red Hat community members

One of the problems that I am having right now is finding people that should be the owners for AeroGear things, such as the website, aerogear.org. If we are going to do this merger, we should clarify the owners of components.

I would like to say that we, as RHMAP core/onprem team, are interested in owning the transition work (not any new components explicitly, but the transition work!) from AeroGear to FeedHenry collaborating with community leaders and members from the both side as well as MCP people.

RHMAP docs team is another group of people that interact with AG and FH quite often and they told me they're here for help whatever direction we go.

Cheers,
Ali

On Wed, Nov 29, 2017 at 5:14 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Nov 22, 2017 at 10:02 AM, Wojciech Trocki <[hidden email]> 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.
In RainCatcher we went even further and created separate web page (that is linked in feedhenry.org). 
This works pretty well as documentation, getting started etc. is exposed directly on the main page.

I think that 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

We can apply similar list to aerogear website - however I'm not aware of the impact or challenges in that area)

On Wed, Nov 22, 2017 at 1:59 PM, Paul Wright <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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
[hidden email]
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.


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

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

pwright
In reply to this post by supittma

Inline


On 11/29/2017 02:14 PM, Summers Pittman wrote:


On Wed, Nov 22, 2017 at 10:02 AM, Wojciech Trocki <[hidden email]> 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 think this 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). 
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 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

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 <[hidden email]> wrote:

Hi AeroGear, FeedHenry

As part of a review of Digger (Build Farm) docs,  I created a PR 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/)

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 over to digger doc on 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
[hidden email]
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.


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

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

Gerard Ryan
In reply to this post by Ali Ok
Ali Ok <[hidden email]> writes:

> I won't go and do a full assessment of both communities/organizations but
> if we're doing this, we should definitely move these things from AeroGear
> to FeedHenry side and make sure they don't break in the future at least the
> current AeroGear things where things are working nicely:
> * Stable processes (release, JIRA workflow, etc.)
> * Open source first mentality (100% community releases, etc.)
> * Somewhat active non Red Hat community members

So at least the last point there (and maybe the second point also?)
would in my opinion be reasons to move everything *to* the AeroGear
community, rather than *from* it to the FeedHenry community.

I don't think it makes a huge difference either way for those of us who
work for Red Hat, since we're involved in / aware of both communities as
they are; but it could be potentially disruptive to the more established
AeroGear open source community.

Since I'm not really involved in that community, I'd like to hear what
matzew or other long-time members of that community think. Maybe it's no
big deal, but I think it's worth thinking about!

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

David Martin
TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community


I would see the FeedHenry community being strongly linked to RHMAP (Red Hat Mobile App Platform). There are large parts of that community that are tied into having access to a an RHMAP cluster e.g. SDKs & templates (There are some exceptions, which I'll call out later). The RHMAP MBaaS is available on github, but it is not very useful without an RHMAP Core. The RHMAP Core is only available via a RH subscription.

I would NOT see the Aerogear community as being strongly tied to RHMAP. The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). Both of these are standalone services that have been developed in an open manner from their inception.
See Ger's points for more about what the Aerogear community is doing well.

Building the Aerogear community as the upstream for mobile in Red Hat would draw a line between what's RHMAP 3.x/4.x and the future (5.x).

Steps from here:
* move the fh-sync-server project into the Aerogear community as the 'Aerogear Data Sync Service'
* move mobile.next()/5.x collateral (that's still relevant after the POC) to the Aerogear community
* progress development of mobile.next()/5.x as the Aerogear community
** update UPS documentation (it reference OpenShift 2! There's been great work done on updating UPS for decoupling keycloak & running on OpenShift 3 via APB)
** add Aerogear Data Sync Service documentation
** add Aerogear Digger/Build Farm documentation
** add Aerogear mobile.next() (name TBD) documentation


I'm sure there's things I've missed, and would welcome other peoples thoughts on this idea.

On 29 November 2017 at 15:25, Gerard Ryan <[hidden email]> wrote:
Ali Ok <[hidden email]> writes:

> I won't go and do a full assessment of both communities/organizations but
> if we're doing this, we should definitely move these things from AeroGear
> to FeedHenry side and make sure they don't break in the future at least the
> current AeroGear things where things are working nicely:
> * Stable processes (release, JIRA workflow, etc.)
> * Open source first mentality (100% community releases, etc.)
> * Somewhat active non Red Hat community members

So at least the last point there (and maybe the second point also?)
would in my opinion be reasons to move everything *to* the AeroGear
community, rather than *from* it to the FeedHenry community.

I don't think it makes a huge difference either way for those of us who
work for Red Hat, since we're involved in / aware of both communities as
they are; but it could be potentially disruptive to the more established
AeroGear open source community.

Since I'm not really involved in that community, I'd like to hear what
matzew or other long-time members of that community think. Maybe it's no
big deal, but I think it's worth thinking about!

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

Wei Li
+1 on Dave's idea to move mobile.next work to the AG community. I would also add that:

* Rethink/Rebrand the objective of the AG project. I think it should be something that is close to what we have for mobile.next
* In the meantime, make it clear that the FH community will still be maintained, but it will only cover for the existing RHMAP projects.

Hopefully this will avoid future confusing around which community is for what purpose. It will also allow us to continue support the AG community that (I think) have more community users than FH.

Thanks.

On Thu, Nov 30, 2017 at 9:49 AM, David Martin <[hidden email]> wrote:
TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community


I would see the FeedHenry community being strongly linked to RHMAP (Red Hat Mobile App Platform). There are large parts of that community that are tied into having access to a an RHMAP cluster e.g. SDKs & templates (There are some exceptions, which I'll call out later). The RHMAP MBaaS is available on github, but it is not very useful without an RHMAP Core. The RHMAP Core is only available via a RH subscription.

I would NOT see the Aerogear community as being strongly tied to RHMAP. The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). Both of these are standalone services that have been developed in an open manner from their inception.
See Ger's points for more about what the Aerogear community is doing well.

Building the Aerogear community as the upstream for mobile in Red Hat would draw a line between what's RHMAP 3.x/4.x and the future (5.x).

Steps from here:
* move the fh-sync-server project into the Aerogear community as the 'Aerogear Data Sync Service'
* move mobile.next()/5.x collateral (that's still relevant after the POC) to the Aerogear community
* progress development of mobile.next()/5.x as the Aerogear community
** update UPS documentation (it reference OpenShift 2! There's been great work done on updating UPS for decoupling keycloak & running on OpenShift 3 via APB)
** add Aerogear Data Sync Service documentation
** add Aerogear Digger/Build Farm documentation
** add Aerogear mobile.next() (name TBD) documentation


I'm sure there's things I've missed, and would welcome other peoples thoughts on this idea.

On 29 November 2017 at 15:25, Gerard Ryan <[hidden email]> wrote:
Ali Ok <[hidden email]> writes:

> I won't go and do a full assessment of both communities/organizations but
> if we're doing this, we should definitely move these things from AeroGear
> to FeedHenry side and make sure they don't break in the future at least the
> current AeroGear things where things are working nicely:
> * Stable processes (release, JIRA workflow, etc.)
> * Open source first mentality (100% community releases, etc.)
> * Somewhat active non Red Hat community members

So at least the last point there (and maybe the second point also?)
would in my opinion be reasons to move everything *to* the AeroGear
community, rather than *from* it to the FeedHenry community.

I don't think it makes a huge difference either way for those of us who
work for Red Hat, since we're involved in / aware of both communities as
they are; but it could be potentially disruptive to the more established
AeroGear open source community.

Since I'm not really involved in that community, I'd like to hear what
matzew or other long-time members of that community think. Maybe it's no
big deal, but I think it's worth thinking about!

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

Wojciech Trocki
TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community

+1 

> update https://aerogear.org

IMHO it's worth also to update page layout and engine (to resolve issues mentioned by Paul) and improve user experience. 

On Thu, Nov 30, 2017 at 11:36 AM, Wei Li <[hidden email]> wrote:
+1 on Dave's idea to move mobile.next work to the AG community. I would also add that:

* Rethink/Rebrand the objective of the AG project. I think it should be something that is close to what we have for mobile.next
* In the meantime, make it clear that the FH community will still be maintained, but it will only cover for the existing RHMAP projects.

Hopefully this will avoid future confusing around which community is for what purpose. It will also allow us to continue support the AG community that (I think) have more community users than FH.

Thanks.

On Thu, Nov 30, 2017 at 9:49 AM, David Martin <[hidden email]> wrote:
TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community


I would see the FeedHenry community being strongly linked to RHMAP (Red Hat Mobile App Platform). There are large parts of that community that are tied into having access to a an RHMAP cluster e.g. SDKs & templates (There are some exceptions, which I'll call out later). The RHMAP MBaaS is available on github, but it is not very useful without an RHMAP Core. The RHMAP Core is only available via a RH subscription.

I would NOT see the Aerogear community as being strongly tied to RHMAP. The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). Both of these are standalone services that have been developed in an open manner from their inception.
See Ger's points for more about what the Aerogear community is doing well.

Building the Aerogear community as the upstream for mobile in Red Hat would draw a line between what's RHMAP 3.x/4.x and the future (5.x).

Steps from here:
* move the fh-sync-server project into the Aerogear community as the 'Aerogear Data Sync Service'
* move mobile.next()/5.x collateral (that's still relevant after the POC) to the Aerogear community
* progress development of mobile.next()/5.x as the Aerogear community
** update UPS documentation (it reference OpenShift 2! There's been great work done on updating UPS for decoupling keycloak & running on OpenShift 3 via APB)
** add Aerogear Data Sync Service documentation
** add Aerogear Digger/Build Farm documentation
** add Aerogear mobile.next() (name TBD) documentation


I'm sure there's things I've missed, and would welcome other peoples thoughts on this idea.

On 29 November 2017 at 15:25, Gerard Ryan <[hidden email]> wrote:
Ali Ok <[hidden email]> writes:

> I won't go and do a full assessment of both communities/organizations but
> if we're doing this, we should definitely move these things from AeroGear
> to FeedHenry side and make sure they don't break in the future at least the
> current AeroGear things where things are working nicely:
> * Stable processes (release, JIRA workflow, etc.)
> * Open source first mentality (100% community releases, etc.)
> * Somewhat active non Red Hat community members

So at least the last point there (and maybe the second point also?)
would in my opinion be reasons to move everything *to* the AeroGear
community, rather than *from* it to the FeedHenry community.

I don't think it makes a huge difference either way for those of us who
work for Red Hat, since we're involved in / aware of both communities as
they are; but it could be potentially disruptive to the more established
AeroGear open source community.

Since I'm not really involved in that community, I'd like to hear what
matzew or other long-time members of that community think. Maybe it's no
big deal, but I think it's worth thinking about!

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

John Frizelle
In reply to this post by Wei Li
Hi All,

I am meeting with OSAS (the Open Source and Standards group) on Monday to discuss our Open Source strategy and plans and where OSAS might be able to assist.

In this meeting I would like to be to give them a definitive answer on where the future of our community lies.

To that end, I would like to ask y'all to take 30 seconds to answer this one question poll - https://goo.gl/forms/k5GsxMbeu2AY632P2 

The poll will remain open for the next 24 hours.

Please take the time to cast your vote in this democratic process :-)

Cheers,
John.


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 30 November 2017 at 11:36, Wei Li <[hidden email]> wrote:
+1 on Dave's idea to move mobile.next work to the AG community. I would also add that:

* Rethink/Rebrand the objective of the AG project. I think it should be something that is close to what we have for mobile.next
* In the meantime, make it clear that the FH community will still be maintained, but it will only cover for the existing RHMAP projects.

Hopefully this will avoid future confusing around which community is for what purpose. It will also allow us to continue support the AG community that (I think) have more community users than FH.

Thanks.

On Thu, Nov 30, 2017 at 9:49 AM, David Martin <[hidden email]> wrote:
TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community


I would see the FeedHenry community being strongly linked to RHMAP (Red Hat Mobile App Platform). There are large parts of that community that are tied into having access to a an RHMAP cluster e.g. SDKs & templates (There are some exceptions, which I'll call out later). The RHMAP MBaaS is available on github, but it is not very useful without an RHMAP Core. The RHMAP Core is only available via a RH subscription.

I would NOT see the Aerogear community as being strongly tied to RHMAP. The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). Both of these are standalone services that have been developed in an open manner from their inception.
See Ger's points for more about what the Aerogear community is doing well.

Building the Aerogear community as the upstream for mobile in Red Hat would draw a line between what's RHMAP 3.x/4.x and the future (5.x).

Steps from here:
* move the fh-sync-server project into the Aerogear community as the 'Aerogear Data Sync Service'
* move mobile.next()/5.x collateral (that's still relevant after the POC) to the Aerogear community
* progress development of mobile.next()/5.x as the Aerogear community
** update UPS documentation (it reference OpenShift 2! There's been great work done on updating UPS for decoupling keycloak & running on OpenShift 3 via APB)
** add Aerogear Data Sync Service documentation
** add Aerogear Digger/Build Farm documentation
** add Aerogear mobile.next() (name TBD) documentation


I'm sure there's things I've missed, and would welcome other peoples thoughts on this idea.

On 29 November 2017 at 15:25, Gerard Ryan <[hidden email]> wrote:
Ali Ok <[hidden email]> writes:

> I won't go and do a full assessment of both communities/organizations but
> if we're doing this, we should definitely move these things from AeroGear
> to FeedHenry side and make sure they don't break in the future at least the
> current AeroGear things where things are working nicely:
> * Stable processes (release, JIRA workflow, etc.)
> * Open source first mentality (100% community releases, etc.)
> * Somewhat active non Red Hat community members

So at least the last point there (and maybe the second point also?)
would in my opinion be reasons to move everything *to* the AeroGear
community, rather than *from* it to the FeedHenry community.

I don't think it makes a huge difference either way for those of us who
work for Red Hat, since we're involved in / aware of both communities as
they are; but it could be potentially disruptive to the more established
AeroGear open source community.

Since I'm not really involved in that community, I'd like to hear what
matzew or other long-time members of that community think. Maybe it's no
big deal, but I think it's worth thinking about!

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upstream Community Documentation

David Martin
An update on this wrt all Mobile.next()/5.x comms.

Immediate change:
The day to day chatter is moving to #aerogear on freenode.
The aerogear-dev mailing list will be used instead of feedhenry-dev.

Eventual changes:
All relevant & new Mobile.next()/5.x repositories will eventually make their way over to the aergear github org https://github.com/aerogear
All Mobile.next()/5.x upstream documentation will be added to aerogear.org

On 30 November 2017 at 13:21, John Frizelle <[hidden email]> wrote:
Hi All,

I am meeting with OSAS (the Open Source and Standards group) on Monday to discuss our Open Source strategy and plans and where OSAS might be able to assist.

In this meeting I would like to be to give them a definitive answer on where the future of our community lies.

To that end, I would like to ask y'all to take 30 seconds to answer this one question poll - https://goo.gl/forms/k5GsxMbeu2AY632P2 

The poll will remain open for the next 24 hours.

Please take the time to cast your vote in this democratic process :-)

Cheers,
John.


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 30 November 2017 at 11:36, Wei Li <[hidden email]> wrote:
+1 on Dave's idea to move mobile.next work to the AG community. I would also add that:

* Rethink/Rebrand the objective of the AG project. I think it should be something that is close to what we have for mobile.next
* In the meantime, make it clear that the FH community will still be maintained, but it will only cover for the existing RHMAP projects.

Hopefully this will avoid future confusing around which community is for what purpose. It will also allow us to continue support the AG community that (I think) have more community users than FH.

Thanks.

On Thu, Nov 30, 2017 at 9:49 AM, David Martin <[hidden email]> wrote:
TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community


I would see the FeedHenry community being strongly linked to RHMAP (Red Hat Mobile App Platform). There are large parts of that community that are tied into having access to a an RHMAP cluster e.g. SDKs & templates (There are some exceptions, which I'll call out later). The RHMAP MBaaS is available on github, but it is not very useful without an RHMAP Core. The RHMAP Core is only available via a RH subscription.

I would NOT see the Aerogear community as being strongly tied to RHMAP. The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). Both of these are standalone services that have been developed in an open manner from their inception.
See Ger's points for more about what the Aerogear community is doing well.

Building the Aerogear community as the upstream for mobile in Red Hat would draw a line between what's RHMAP 3.x/4.x and the future (5.x).

Steps from here:
* move the fh-sync-server project into the Aerogear community as the 'Aerogear Data Sync Service'
* move mobile.next()/5.x collateral (that's still relevant after the POC) to the Aerogear community
* progress development of mobile.next()/5.x as the Aerogear community
** update UPS documentation (it reference OpenShift 2! There's been great work done on updating UPS for decoupling keycloak & running on OpenShift 3 via APB)
** add Aerogear Data Sync Service documentation
** add Aerogear Digger/Build Farm documentation
** add Aerogear mobile.next() (name TBD) documentation


I'm sure there's things I've missed, and would welcome other peoples thoughts on this idea.

On 29 November 2017 at 15:25, Gerard Ryan <[hidden email]> wrote:
Ali Ok <[hidden email]> writes:

> I won't go and do a full assessment of both communities/organizations but
> if we're doing this, we should definitely move these things from AeroGear
> to FeedHenry side and make sure they don't break in the future at least the
> current AeroGear things where things are working nicely:
> * Stable processes (release, JIRA workflow, etc.)
> * Open source first mentality (100% community releases, etc.)
> * Somewhat active non Red Hat community members

So at least the last point there (and maybe the second point also?)
would in my opinion be reasons to move everything *to* the AeroGear
community, rather than *from* it to the FeedHenry community.

I don't think it makes a huge difference either way for those of us who
work for Red Hat, since we're involved in / aware of both communities as
they are; but it could be potentially disruptive to the more established
AeroGear open source community.

Since I'm not really involved in that community, I'd like to hear what
matzew or other long-time members of that community think. Maybe it's no
big deal, but I think it's worth thinking about!

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev





--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev