Also we should jab them with forks.
On 13 June 2011 19:28, Paul Davis <[email protected]> wrote: > On Mon, Jun 13, 2011 at 2:27 PM, Robert Newson <[email protected]> > wrote: >> +1 for commit requirement in addition to being a release requirement. >> At the very least, we get the docs fixed during the release process, >> but it ought to be done with the commit itself. In practice, we'll >> forget sometimes, and then be reminded by others on the team. >> > > Right. I'm saying "reminded by others" should be "commit vetoed". > >> B. >> >> On 13 June 2011 19:17, Robert Dionne <[email protected]> wrote: >>> ++1++ >>> >>> On Jun 13, 2011, at 2:08 PM, Paul Davis wrote: >>> >>>> On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson <[email protected]> >>>> wrote: >>>>> It's not the wiki per se that bothers me, it's that it's the primary, >>>>> often only, source of documentation. >>>>> >>>>> I propose that future releases of CouchDB include at least a full >>>>> description of all public API's. Improvements above that base level >>>>> would be a manual and/or simple tutorials. >>>>> >>>>> This documentation would be maintained in the same source tree as the >>>>> code and it would be a release requirement for this documentation to >>>>> be updated to include all new features. >>>>> >>>> >>>> You had me until you said "release requirement". I would upgrade that >>>> to "commit requirement" if we're seriously about having such >>>> documentation. If we don't force people to make sure docs reflect >>>> changes at commit time then its probably going to be a lost cause. >>>> >>>>> This documentation is then the primary source, the wiki can serve as a >>>>> supplement. >>>>> >>>>> b. >>>>> >>>>> On 13 June 2011 18:16, Peter Nolan <[email protected]> wrote: >>>>>> Any documentation is good. >>>>>> >>>>>> What is this 'spam'? Haven't personally encountered anything on the wiki >>>>>> that would be 'considered' spam (perhaps not stumbled upon that portion?) >>>>>> >>>>>> But it's inevitable that the wiki will be attacked by unscrupulous people >>>>>> and as such, the wiki should prepare for this. The wiki is going to need >>>>>> gatekeepers/admins to maintain it. >>>>>> >>>>>> It would be nice, that any edits be archived so users can see previous >>>>>> states of the page if they so choose so. >>>>>> >>>>>> >>>>>> If a noted jerk keeps editing the wiki, we should have a system that only >>>>>> applies his edits to his account. The common user would not see his >>>>>> edits, >>>>>> only he would, which would hopefully convince him that his edit has gone >>>>>> through. >>>>>> >>>>>> +1 top hats. >>>>>> >>>>> >>> >>> >> >
