Menu
▾
▴
Re: [Plone-docs] collective.developermanual is now on plone.org
|
From: Dylan J. <dy...@dy...> - 2010-01-28 04:10:07
|
On 28/01/2010, at 9:03 AM, Alexander Limi <li...@pl...> wrote: > Indeed. Ask on plone-dev what people would be most comfortable with. > My guess (hope? ;) is: > Manual maintained in SVN, by Plone Committers (as it's easy to get > commit rights, I don't see this as being fundamentally different > from putting it in the Collective, and solves the ownership/ > licensing issue), > Should be an official front-and-center manual in the docs area, > Maintained as part of a Plone release (meaning, we can fork it for > Plone 4, etc when needed) +1 esp. to branches on release. /documentation/manual/developermanual/plone4/index Are now maintainable with svn and the collective manual. (as much as i wish it was just with plone too) > > On Wed, Jan 27, 2010 at 12:43 PM, Anne Bowtell <ann...@me... > > wrote: > + 1 > > I vote for whatever will get the developer documentation written and > maintained most effectively. > > Anne > > > On 27/01/2010 18:40, Veda Williams wrote: >> >> My 2 cents here is that I am not a developer, but it would be worth >> pulling in the core developers to see what their feelings are about >> sphinx vs. Plone. Whoever is most likely to contribute should have >> their vote weighed more in this decision... >> >> And I agree, work-o-cracy is probably the way to go here. >> >> As a suggestion, I see no reason why the manuals page could not be >> updated (perhaps by hand) to point to the KB manual. That way it’s >> available in both placed and editable by anyone. >> >> Veda Williams >> Web Developer >> Groundwire >> 206.286.1235x23 >> ve...@gr... >> ONE/Northwest is now Groundwire! Read all about our new name. >> >> >> >> On 1/27/10 7:40 AM, "Israel Saeta Pérez" <duk...@gm...> wrote: >> >> Hello, >> >> 2010/1/27 Dylan Jay <dy...@dy...> >> Hi, >> >> The idea is to have one developer manual right? Otherwise it's >> going to be confusing where to put what. >> >> >> Actually I'm not sure of this at all. Manuals and stuff in the KB >> can coexist. Only the policies for the two areas are different, and >> we explicitly agreed on the split specially because of the >> different policies available for choice. >> >> >> The way I see it we have two potential contenders of the "one" >> plone development manual, the existing plone.org <http:// >> plone.org> manual and the new collective manual. Each has a >> different update process but both are trying to be the same thing. >> >> I'm not sure what the process is for making this decision. Are >> there still documentation team meetings where stuff is decided. Is >> this open for debate? Anyone know? >> >> >> We still have an Editors Team which should ideally be responsible >> of making the decisions, but in practice it has so few members that >> I think we will have to apply a work-o-cracy: the people who works >> (or have worked) decide. This includes, in my opinion, most of the >> editors and Veda, Steve, Anne Botwell, Kamon, John Stahl, Alex, >> Mikko, Martin and you among others. >> >> Hopefully I've answered Israel's questions about structure and >> quality of the collective documentation further down. The options I >> can think of are: >> >> a) Let both manuals exist for a couple of months side by side in >> the manuals area and then decide which to keep after that. >> Basically experiment with the update process and see what produces >> better content and which contributors and readers prefer. >> >> b) Let both manuals exist for a couple of months, one in manuals >> section, one in kb, and then decide which to keep after that >> >> >> The manuals area is the manuals area because of its policies. As >> I've already said in my previous email, the >> collective.developermanual needs to live in the KB if we want to >> respect these policies. So the only valid option above would be (b). >> >> The rest of options involve deciding now and I'd prefer to live >> with both for some time, since I'm not sure at all of which one >> will work best. IMO it's better and easier to try and see. >> >> -- israel >> >> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> The Planet: dedicated and managed hosting, cloud storage, colocation >> Stay online with enterprise data centers and the best network in >> the business >> Choose flexible plans and management services without long-term >> contracts >> Personal 24x7 support from experience hosting pros just a phone >> call away. >> http://p.sf.net/sfu/theplanet-com >> _______________________________________________ >> Plone-docs mailing list >> Plo...@li... >> https://lists.sourceforge.net/lists/listinfo/plone-docs > > > --- > --- > --- > --------------------------------------------------------------------- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term > contracts > Personal 24x7 support from experience hosting pros just a phone call > away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Plone-docs mailing list > Plo...@li... > https://lists.sourceforge.net/lists/listinfo/plone-docs > > > > > -- > Alexander Limi · http://limi.net > --- > --- > --- > --------------------------------------------------------------------- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term > contracts > Personal 24x7 support from experience hosting pros just a phone call > away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Plone-docs mailing list > Plo...@li... > https://lists.sourceforge.net/lists/listinfo/plone-docs |