Hi Steve,
I didn't know of GitBook before.
I was thinking if we can embed links in the
documentation to the actual branch/documentation-file in Github.
Something like a side arrow that, when being clicked, it can navigate to
the GitHub page hosting the actual file that rendered this HTML resource.
This way, the user can:
- suggest typos or corrections
- try to add suggestions, through pull-rquests
- add comments to something that's not clear for them
What do you think?
Vlad
On Thu, Nov 19, 2015 at 4:16 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
Vlad, back to your original question... What specifically did you
mean?
Are you talking about something like
https://github.com/integrations/gitbook ?
On Fri, Nov 13, 2015 at 3:39 PM Steve Ebersole <steve(a)hibernate.org>
wrote:
> On Fri, Nov 13, 2015 at 3:30 PM Hardy Ferentschik <hardy(a)hibernate.org>
> wrote:
>
>> Hi,
>>
>> On Wed, Nov 11, 2015 at 02:36:13PM +0000, Steve Ebersole wrote:
>> > I think it makes sense to host these on
hibernate.org *after* we
>> figure out
>> > the version-specific content issues I brought up in Barcelona.
>>
>> What issues are you talking about. I know you want to link to different
>> versions of the documentation from
hibernate.org. AFAIK you already
>> started
>> with it and made some progress.
>>
>
> I made progress on version-specific documentation. But there is really
> all kinds of version-specific data-points on the website in addition to
> documentation. Rather than me cobbling it together piecemeal for each data
> point, I proposed that we consider an overall strategy for version specific
> information on the website.
>
>
>
>> > However, I am kind of torn. Unless I misunderstand that would mean
>> moving
>> > the sources out of the upstream projects into the
hibernate.org git
>> repo.
>>
>> Really, why is that?
>>
>
> What's the other option? Keeping it upstream, building the docs and
> somehow pushing those built artifacts into the
hibernate.org git repo?
> Or do y'all mean defining a scp/ftp/rsync dir on the actual box? Because
> today we seem to strive for scriptable rebuilding...
>
>