Sounds like a good goal, but I don't think Tomaz should be responsible for correcting all our docs to make them conform. For many of these I doubt the Confluence markup includes relevant metadata that would have allowed that (e.g. that a given literal was a filename, hence [filename]`thename` instead of `thename`. We'd need to assign owners to various pages and have them correct them. An obvious initial owner being the component lead for the component that's most relevant to the page._______________________________________________On Wed, Nov 8, 2017 at 7:04 AM, David Lloyd <firstname.lastname@example.org> wrote:I would suggest that we ensure that our produced AsciiDoc files
conform to  (generated from ). Beyond that, I support this
On Tue, Nov 7, 2017 at 12:06 PM, Brian Stansberry
> Since we're done with WF 11, I think it's time to move forward on this.
> There's still some discussion to have about decomposing the docs so the
> relevant doc bits are aligned with the feature packs they come from, but I
> haven't heard any argument against moving off Confluence and having the docs
> included in the source tree. Since we don't have the current docs decomposed
> in any way, I see no reason not to go ahead with bringing the docs in
> wildfly/wildfly master and then we can deal with decomposition as a later
> On Tue, Sep 19, 2017 at 7:58 AM, Tomaž Cerar <email@example.com> wrote:
>> Hey guys,
>> I've converted confluence docs asciidoc   ones that will be part of
>> WildFly codebase,
>> take a look at them and let me know if there are any big issues.
>> full version:
>> as most of you already know, I was working on moving our confluence based
>>  documentation to asciidoc based one.
>> result can be seen at  or rendered to html at 
>> A good side effect of conversion is that now docs are also browsable
>> directly on GitHub.
>> For example  or 
>> Currently I kept same structure as we had in confluence, which in practice
>> we have set of "guides" that than have lots of sub pages / includes that
>> produce "big" guides.
>> Currently such guides are:
>> - Admin Guide
>> - Developer Guide
>> - Getting started guide
>> - Getting Started Developing Applications Guide
>> - High Availability Guide
>> - Extending WildFly guide
>> - JavaEE 7(6 actually) Tutorial
>> - Elytron security guide
>> - quickstarts
>> - Testsuite
>> Problem is that some of this guide as such make sense, but not all of them
>> In some cases we have duplicated docs for same thing, in others we content
>> in wrong segment.
>> For example instead of having all subsystem reference docs under admin
>> some are under Developer Guide and some even under HA guide.
>> Going forward we should "refactor" docs a bit, so we would end up with 3-4
>> high quality guides.
>> We should also go trough all docs and remove/update the outdated content.
>> Plan is also to have documentation now part of WildFly codebase.
>> So when we would submit PR with new feature, it would also include
>> documentation for it as well.
>> Rendered docs can be build as part of our build / release process and can
>> be rendered to different formats.
>> for example default is HTML  or PDF 
>> I've send experimental PR to show how docs would fit into WildFly build
>> Please take look at current docs and if you have any comments /
>> suggestions what we can improve before merging it let me know.
>> At this point I've not done much content-wise changes but just conversion
>> + formatting ones.
>> Content updates can come after this is merged.
>>  https://docs.jboss.org/author/display/WFLY/Documentation
>>  https://github.com/wildfly/wildfly/pull/10523
>>  https://ctomc.github.io/docs-playground/Admin_Guide.html
>>  https://ctomc.github.io/docs-playground/Admin_Guide.pdf
>>  https://github.com/ctomc/docs-playground
>>  https://ctomc.github.io/docs-playground/
>> wildfly-dev mailing list
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
> wildfly-dev mailing list
--Brian StansberryManager, Senior Principal Software EngineerRed Hat
wildfly-dev mailing list