> > Is that a matter of familiarity and/or legacy? > > Are there existing docs managed by grav that want importing? AFAIK there are no legacy requirements, and we want to be as open and transparent a community as possible. I'd really like this to be here is everything in a flat repo, so any external contributors are as empowered to make changes as a Miracl staff member. We already do public development, with pull requests as our internal workflow, and I think that us publishing JSON for content and HTML for layout from a public git repo is a fairly low bar to entry.
I'm a little uncomfortable with us *needing* more than that for documentation, as it suggest some business process is being delegated to tooling. If we have business needs to accommodate, we should split this off into a possibly internal discussion on how *PE* and *DEVOPS* can best support these needs. Otherwise, I'd prefer that docs are stored alongside code in git, and are handled like code. I'd would like to avoid any "in-house only" magic to produce docs especially where we must engage with people who cannot use such visual tools due to visual impairment or other accessibility needs. Using a "Git first" workflow will allow us to support email, web, users of assistive technologies, as well as a range of desktop and mobile clients. On Wed, Apr 6, 2016 at 1:38 PM, Nick Kew <[email protected]> wrote: > On Wed, 6 Apr 2016 14:36:49 +0300 > Vladislav Mitov <[email protected]> wrote: > > > I agree with Jamal. We can build it with some kind of static site > > generator for convenience, but we don't need this thing on the server > > for sure. > > Indeed. Existing apache projects use a range of publishing > models and templates. We could certainly ping infra about > using the Apache CMS if some folks would prefer, but I think > they'd want a pretty compelling case to support a whole new > system. > > The most likely trigger to adopt it would be demand coming > from a range of projects. As in, when git was introduced, > or arguably even when svn replaced cvs! > > > > > That is why it is extremely important to have it clear, > > > > understandable, and even more important - easy to access and edit > > > > if needed. > > That is a problem to which many solutions are available. > > > > > > > > > Having that in mind I want to raise a discussion here about using > > > > a GRAV https://getgrav.org > > > > This is flat file CMS, with no backend database to support. > > Is that a matter of familiarity and/or legacy? > Are there existing docs managed by grav that want importing? > > Bear in mind that unless there's a pretty substantial legacy > to deal with, committers can be expected to come from a range > of different backgrounds and adapt to whatever tools are used > for a particular project. > > -- > Nick Kew >
