From: Dylan J. <dy...@dy...> - 2010-01-31 23:57:46
|
On 28/01/2010, at 5:40 AM, 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... Sounds good but we didn't get much reaction either way last time we asked. My concern is from a product design perspective it's often less useful to ask a customer what they want but instead make a prototype and sit down with them and see if and how they use it. What would be a fair prototype? Make it public on plone.org and really outline the process of how it would work and see if anyone starts contributing maybe? > > 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 |