Re: [PHP-DEV] RFC: documentation collaboration toolchain
Hi! I) Wiki One option is to setup a wiki, the proposed choice was using dokuwiki, which seems to support a flexibile auth system (so that we can use cvs auth by default and fall back to a dokuwiki account for new guys that do not yet have a cvs account), ACL's (so that we can control where new guys can play around), namespaces (so that we can structure related content), breadcrumb navigation, history/diffing. For a full feature list look here [10]. Of course its PHP and OSS, so we can hack on it as we please. I'm for using wiki for brainstorm-stage projects - basically anybody with a crazy idea backed by some explanations, examples, etc. should be able to place it into the wiki and have it there for discussion. There should be very relaxed procedure on giving auth there - basically anybody who's not a troll or a bot should be able to play :) For projects that are in more accepted state - i.e. ones that we know we want to do in PHP and have good idea how, or TODO items that are agreed upon and just waiting for people to take care of them - CVS-based system like reST sounds better. These docs would be mostly static and for informational purposes - like NEWS etc. Current CVS accounts would be enough for those, since people that have reason to edit them probably would be people already holding CVS account anyway. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: documentation collaboration toolchain
Hello Lukas, Monday, February 25, 2008, 5:04:45 PM, Pierre wrote: On Mon, Feb 25, 2008 at 3:59 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008, Lukas Kahwe Smith wrote: Personally I prefer going with a wiki, because I do not have much affection with CVS for these kinds of documents (actually I do think that the README's should be in CVS, which is why I worked with Hannes on creating the current php.net/reST interface). I have put this document up on my wiki [12], and I will keep it uptodate. I'd go for RFC in CVS/Rest, and the todo's in a wiki. Limiting the RFC to existing php.net's member sound like a bad idea and create CVS accounts only for a RFC does not sound any better. I would rather use the wiki for the complete process. Once a RFC reached a stable status, we can add it to a RFC repository. VC are perfect for source codes and relatively static contents but nor for documents edition like what we need for RFC, todos or other similar documents (no source code). We should have all such docs on a WiKi with ACLs reflecting CVS accounts and additional WiKi specific accounts. As Pierre points out correctly, having to give every newcomer for every idea a CVS Access is pretty bad. Maybe the bast way to do it is to control that by our user database. Very easy, or is this too easy? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: documentation collaboration toolchain
On 25.02.2008, at 17:20, Stefan Marr wrote: Pierre Joye schrieb: Limiting the RFC to existing php.net's member sound like a bad idea and create CVS accounts only for a RFC does not sound any better. I would rather use the wiki for the complete process. Once a RFC reached a stable status, we can add it to a RFC repository. Would agree on this. For me at would have been a burden to get such an account upfront. Since I'm not part of the core dev team. I will try and look if I can make dokuwiki work using a reST syntax and CVS as storage (this is possible since dokuwiki stores all content as plain text files with no additional metadata). Anyone willing to help please email me offlist as I do not think that this should clog up this mailinglist. But let me briefly detail what I would want to do (feel free to also email me offlist that I am an idiot for trying this and why you think so): 1) Authentication is done against master.php.net, but falls back to a dokuwiki db, but only if the provided username does not exist in master.php.net to prevent people from highjacking a CVS account name on the wiki. This authentication interface does not yet exist on master.php.net and Hannes tentatively agreed to implement it. 2) Edits on the web interface will commit to CVS. In a first step I would use a single user, eventually I might try to look into committing as a specific user if the wiki user was authenticated via master.php.net, but there are of course (solveable) security implications here (until then people with a CVS account should use that to ensure proper log history). Note that dokuwiki supports an optimistic locking approach, where it allows you to manually resolve a conflict (diff provided) when someone does a change in between opening the edit form and submitting. This is of course important since CVS commits can not be protected by pessimistic locks that dokuwiki also supports. 3) Now on the CVS side I would say we should have a new repository. I would need to implement some post commit hooks that will leverage the dokuwiki CLI interface to ensure that meta data is updated accordingly. Open question is if its even possible to have a post commit hook specifically for just one CVS repo. In the end it should however be possible for people to edit files inside CVS without ever doing anything with the web interface. On the web interface side the only thing will be that CVS users will by pass the pessimistic locking (maybe we will just disable it for consistency .. I prefer optimistic locking anyways). Also we still have the ability of providing any content on the wiki along the lines of what we have with php.net/reST at the moment. On top of that we can grant people access to the wiki (or parts of the wiki) without much hesitation. As a result we could even provide the accounts for RFC's maybe even via an automated process. Commits of these people will of course be done with a standard user account, so the history on the wiki will be the only way to tell who did what. This is obviously solveable by given that person a CVS account quickly. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: documentation collaboration toolchain
On Sat, 23 Feb 2008, Lukas Kahwe Smith wrote: Personally I prefer going with a wiki, because I do not have much affection with CVS for these kinds of documents (actually I do think that the README's should be in CVS, which is why I worked with Hannes on creating the current php.net/reST interface). I have put this document up on my wiki [12], and I will keep it uptodate. I'd go for RFC in CVS/Rest, and the todo's in a wiki. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: documentation collaboration toolchain
On Mon, Feb 25, 2008 at 3:59 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008, Lukas Kahwe Smith wrote: Personally I prefer going with a wiki, because I do not have much affection with CVS for these kinds of documents (actually I do think that the README's should be in CVS, which is why I worked with Hannes on creating the current php.net/reST interface). I have put this document up on my wiki [12], and I will keep it uptodate. I'd go for RFC in CVS/Rest, and the todo's in a wiki. Limiting the RFC to existing php.net's member sound like a bad idea and create CVS accounts only for a RFC does not sound any better. I would rather use the wiki for the complete process. Once a RFC reached a stable status, we can add it to a RFC repository. VC are perfect for source codes and relatively static contents but nor for documents edition like what we need for RFC, todos or other similar documents (no source code). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: documentation collaboration toolchain
Pierre Joye schrieb: Limiting the RFC to existing php.net's member sound like a bad idea and create CVS accounts only for a RFC does not sound any better. I would rather use the wiki for the complete process. Once a RFC reached a stable status, we can add it to a RFC repository. Would agree on this. For me at would have been a burden to get such an account upfront. Since I'm not part of the core dev team. Kind Regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
