: But that also makes it important that any committer is given good tools
: to make sure her edits look good. I hope Asciidoc is more standardised
: than Markdown, else your choice of tooling may ultimately decide whether
: your edits look good or bad.
Asciidoc(tor) is much more standardized a
+1
I’m happy we can finally move on with this.
And agree with Hoss that docs must be expected with code, or else the released
git version will not contain the correct refguide. We cannot rely on releasing
the refguide weeks after the code anymore, and we can’t hold up the release
process and do
: *) should there be LICENCE on the Github repo if you want people to
: play/experiment/contribute ideas?
I'm not sure that's really neccessary at this point -- so far all of the
contributions have been from existing committers, and we (probably?) don't
want to take on any (new) significant con
Silly things:
*) should there be LICENCE on the Github repo if you want people to
play/experiment/contribute ideas?
*) This part is future, right? "Custom Java tooling will be used to
process the .adoc file metadata to build up navigation data files" I
can't find it in the repo, but maybe I am con
It's been a while, but I (with Hoss' assistance) have been doing some
work on the proposal I made last summer to move the Ref Guide off of
Confluence. In my opinion, we're really close to being ready to make
this move, and I'd like to make it before Solr 7, and maybe even by
6.5 (partially, at leas