From kde-core-devel Wed Aug 25 14:52:32 2004 From: Aaron Seigo Date: Wed, 25 Aug 2004 14:52:32 +0000 To: kde-core-devel Subject: Re: KDE HIG, CIG and AG Message-Id: <200408251652.32525.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109344573805909 On Wednesday 25 August 2004 16:18, Friedrich W. H. Kossebau wrote: > Is access control really needed? Where is the trust among the KDE > community? first off, i don't see ACLs needed as much as a process that we all just respect. if people go committing bodies of new content as a way to end-run the processes, then we may need ACLs. otherwise i don't see the need for ACLs. we simply need to coordinate and create consensus before adding to the guidelines; these are documents with tremendous ramifications for the project. so control is needed. it isn't as much a matter of trust as it is of logistics. guidelines are more like documentation than code, and we know what we have learned from that: you need to be careful for reasons of consistency, translation and cvs conflicts to coordinate changes to the repository carefully. these are also guidelines that will last for years and must reflect the needs of usability, accessability and community identity. this really requires a process that isn't "cats herding themselves" as we do (very effectively) when writing code. to be honest, this is probably one of the more trivial points within the proposal. we have everyone here who actually contributed to the old styleguide, as well as all the people who will be authoring the new AG and CIG. so we have very good representation at aKademy, and we covered a lot more interesting and exciting events during the BOF like actually having the (wo)man-power to write these guidelines available to us! =) > Doesn't it work in all other cvs modules (except www, for > whatever reason) www has them because it's both public and paragraph-based documentation. > Are guideline writers more special than code writers? it's not about the writers being special. it's about the content having different requirements. > What about missspelled words or syntax errors? Should we really wait until > the maintainer had the time to review the little fix? please send a patch to the mailing list first. given the paragraph based nature of guidelines, such fixes must be coordinated with the maintainers even more so than they are in code due to the merging nightmares this can create (and has created in the past in documentation). having a spelling error in the file for a few days won't have any practical negative effects, really. > Please, give a reasoning for this. does this make it any clearer for you, or are there remaining questions that linger for you? -- Aaron Seigo, currently in Ludwigsburg KDE World Conference 2004: aKademy