On Thu, Sep 7, 2023 at 11:40 PM Jeff Mesnil <jmesnil@redhat.com> wrote:


On 7 Sep 2023, at 22:45, James Perkins <jperkins@redhat.com> wrote:

The source of these guides would be in https://github.com/wildfly/wildfly/tree/main/docs/src/main/asciidoc. Having the doc being closer to the source will incentivize developers to add and maintain them :)

I actually think keeping these elsewhere makes more sense. They should likely just live in https://github.com/wildfly/wildfly.org or a separate repository all together. If we need to update a guide because it has an error, how would we do that? If we just make a PR to the main WildFly repo, we'd need a release to see the change.

Technically, we don’t need to release WildFly to push its content to wildfly.org, we would just copy its content.
But this might be inappropriate if it picks up a guide for something that has not been released yet.

I like your other approach and we can make it a seamless integration:

* have a dedicated github.com/wildfly/guides that contains the guides (in Asciidoc) as well as the same web site L&F than wildfly.org
* use GitHub page to publish it to https://docs.wildfly.org/guides

With that setup, we could aded/update guides independently of WildFly releases.

I think this makes sense and I like this approach.

Along these lines, because I'm thinking about this for another project, is for new feature guides maybe we have a dev branch or something that once released we merge into the main branch. That way we can create guides for new releases without affecting the current guides. The other option is just labels and merging when released.
 

Jeff


Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/



--
James R. Perkins
JBoss by Red Hat