Starting a new thread on this topic. I think we all think moving to github hosted infrastructure will be good. Plus it will give us a chance to clean out some old content.
So as I see it this is what has to happen.
We port any content from the confluence wiki to the github wiki. I am thinking this includes everything linkable from the home page (linkable and not external like docs, etc… ). This includes:
Download pages
GSIPs
RnD (mostly irrelevant but might be a few pages we want to save)
Roadmap (not in its current form but more or less just the release schedule)
Mailing Lists, Contributors, etc…
Porting all of this content to the github wiki would be time consuming. I am wondering if a reasonable approach would be to export the current contents of the wiki that we care about and host them as html. Basically just for historical purposes. And then for new content: GSIP’s, RnD and Download pages, we would use the github wiki.
We dump the static frontpage of geoserver.org into a gh-pages branch in our repo. We’ll have to update all the side bar links to point to the wiki content.
Thoughts?
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
What about porting that stuff to sphinx, and generating the pages? You can still edit the RST in github and the result is a bit more under our control for LnF.
I am happy to do the github pages move, as uDig is done that way now. We should ask frank if there were any glitches setting that up.
Starting a new thread on this topic. I think we all think moving to github hosted infrastructure will be good. Plus it will give us a chance to clean out some old content.
So as I see it this is what has to happen.
We port any content from the confluence wiki to the github wiki. I am thinking this includes everything linkable from the home page (linkable and not external like docs, etc… ). This includes:
Download pages
GSIPs
RnD (mostly irrelevant but might be a few pages we want to save)
Roadmap (not in its current form but more or less just the release schedule)
Mailing Lists, Contributors, etc…
Porting all of this content to the github wiki would be time consuming. I am wondering if a reasonable approach would be to export the current contents of the wiki that we care about and host them as html. Basically just for historical purposes. And then for new content: GSIP’s, RnD and Download pages, we would use the github wiki.
We dump the static frontpage of geoserver.org into a gh-pages branch in our repo. We’ll have to update all the side bar links to point to the wiki content.
Thoughts?
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
On Thu, Aug 1, 2013 at 8:50 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:
What about porting that stuff to sphinx, and generating the pages? You can
still edit the RST in github and the result is a bit more under our control
for LnF.
Hum, what's LnF? Look and Feel?
Anyways, I have the impression that for proposals Sphinx might not be that
great, I mean, editing it can be a bit annoying for those
that are not used to it.
Is it just me, or github pages has some sort of online editor? There seems
to be a screenshot, but I cannot find docs for it.
I am happy to do the github pages move, as uDig is done that way now. We
should ask frank if there were any glitches setting that up.
Yep. How was the migration done? (you were using confluence too before,
right?)
And how is the maintenance done? (editing existing content, generating new
pages and so on)
Personally i think it makes sense to use the wiki for the more dynamic content like proposals and downloads and keep the gh-pages content to really only the static content like the homepage, etc…
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
What about porting that stuff to sphinx, and generating the pages? You can still edit the RST in github and the result is a bit more under our control for LnF.
Hum, what’s LnF? Look and Feel?
Anyways, I have the impression that for proposals Sphinx might not be that great, I mean, editing it can be a bit annoying for those
that are not used to it.
Is it just me, or github pages has some sort of online editor? There seems to be a screenshot, but I cannot find docs for it.
I am happy to do the github pages move, as uDig is done that way now. We should ask frank if there were any glitches setting that up.
Yep. How was the migration done? (you were using confluence too before, right?)
And how is the maintenance done? (editing existing content, generating new pages and so on)
Anyways, I have the impression that for proposals Sphinx might not be that great, I mean, editing it can be a bit annoying for those
that are not used to it.
It is the same editor for the github wiki. I was not very impressed with the github wiki, it lets you change between different markup formats on a page by page basis. I cannot remember if the inter page linking updates when you rename a page or not.
I am happy to do the github pages move, as uDig is done that way now. We should ask frank if there were any glitches setting that up.
Yep. How was the migration done? (you were using confluence too before, right?)
Confluence uses textile, which was one of the formats the github wiki supports. So I tried porting just the textile (ripping it out of the XML) - and failed due to the amount of differences (especially around linking).
Eventually found it easier to export the html, and then convert the result to RST (using pandoc) and then write some java code to clean up the mess.
And how is the maintenance done? (editing existing content, generating new pages and so on)
We edit the RST (just like for geotools and GeoServer) you can edit from github if needed. And then generate the html out into website checkout, and then commit.