> Hello > > I've been thinking lately about how we can make it easier for people > to contribute to the project..
The bigest block to me getting more involved is SVN and the lack of offline tools that will work with how Docbook is implemented by the project (piecemeal files that a DocBook editor cannot include automatically for validation). > The OE was a great improvement and made it whole lot simpler to get > going for users and did its job pretty well. It is, but it's still a lot of work to do anything more than simple edits. It also blocks further edits once one is saved, even if it isn't made into a patch. Also, the number of contributions that have been awaiting review for weeks, does nothing to encourage potential contributors. Even if a contribution is rejected, provided it is done with constructive comments, is better than stagnating in the OE, potentially holding up further commits to the same document. > Editing xml however isn't something the general public seems to be > willing to do, not to mention they have no idea what docbook is at > all. True, but PHP users aren't the general public, most are at least familar, if not experienced, with it > Other pain points are how long it takes to validate and build the > documentation - and the cheesy tricks we've had to deploy to squeeze > every performance drop out of both PHP and XML. Much of this pain seems to be because of implementation details, see above comment concerning offline tools > If you guys remember our story.. > DSSSL rendering took _days_ to build. > XSLT took _hours_. > PhD takes _minutes_. > I think we can do better. > I want it down to _seconds_. > I've been toying with the idea of retiring my baby on its 6year old > birthday early October.. And replace it with something new. Faster. > Easier. Better. > I however don't think we can do that with XML. > And I want to make it even easier to contribute - with essentially no > learning curve. > What do you guys think? :) I suggest fixing the above problems first. Changing the format without getting rid of these bottle-necks will be a superficial change. One that will cause many current contributors to have to learn a new format, regardless of which is chosen The biggest help to me, and to many others I believe, would be moving the documentation project to Github. Easy forking, commiting, followed by pull requests that don't block other peoples work would speed the process. Provided of course that the PRs get reviewed. > -Hannes
