Re: collective.developermanual is now on plone.org

Forgot to say that whatever way we go it really needs to be a  
consensus between those that currently write dev docs in addition to  
considering how it could bring in new people.  I havnt contributed to  
either manual. I intend to however It takes me ages to write things  
that are clear. My point is I don't recommend option c if a frequent  
contributor such as Israel doesn't want to contribute any more.

Dylan Jay
Technical solution manager
PretaWeb 99552830

On 28/01/2010, at 10:43 AM, Dylan Jay <[email protected]> wrote:

> On 28/01/2010, at 2:40 AM, Israel Saeta Pérez wrote:
>
>>
>> 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 collective developermanual is really a third policy that doesn't  
> fit into either camp.
>
>>
>> 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.
>
> I was thinking the same however the downside in that approach is  
> that we might not give either a real "try". Since we'd have two  
> competing manuals we'd be splitting the contributors and the real  
> problem all these docs changes are trying to solve is to get more  
> people maintaining documentation.
> If we pick c) and go out to the developer/integrator community with  
> a strong message saying "contribute here" we should get more uptake  
> than if we say "we haven't worked it out yet". People want to  
> contribute to something that will keep on living (plus lots of  
> people do nothing when confronted with a non obvious choice even if  
> nothing is worse than choosing). Of course this option is only going  
> to work
>
> The potential downside of c) is that after a few months we find the  
> manual isn't getting maintained by anyone new or the quality is crap  
> and so we pull the plug. Fortunately we'd have a fully plone  
> editable version of the collective manual due to the conversion  
> process we use so no downtime there. It would just be a matter of  
> deleting the collective manual and telling contributors they need to  
> go plone.org to edit the manual now.
>
> We'd have to convert the current plone.org manual (and the tutorials  
> to be merged in) into reST. There exists python code to do that  
> conversion so I'll write transmogrify.html2rest and we'd have a  
> funnelweb commandline to pull down any plone content into local txt  
> files.
>
> So I don't really see the downside in c).

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/plone-docs