KDE HIG, CIG and AG

[Friedrich W. H. Kossebau]

First, I beg your pardon that I do not comment on the more important part of 
your first email. I appreciate all the efforts to get 1980's UI and app 
design in a more usable direction, at least by consistency :) I thank you all 
for doing so, really. 

Am Mittwoch, 25. August 2004 16:52 schrieb Aaron Seigo:
> 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. 

Hu? Everyone involved would know about the problems. No need for ACLs. And 
someone not involved would not even try to commit something, or?

> 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.

Okay, if such problems were experienced I could understand this as a 
self-protection. Still I feel sad about it. I would be in favor for simple 
guidelines which say what to do and how and what not to do. 

> > 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.

The public argument taken. Although some api comment in code would get public 
(api.kde.org), too. But not that prominently, I admit. The paragraph one, I 
don't know.

> > 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.

So all on the mailing list can commit? And, you missed the point about the 
syntax error. In my experience flexibility is better than restrictivity. What 
if the maintainers are on vacation, overworked or worse? Flipping the ACLs 
would not please the admin ;)

> > Please, give a reasoning for this.
>
> does this make it any clearer for you, or are there remaining questions
> that linger for you?

I voiced my opinon and was heared. Thank you and the other for the answer :)
That were all my cents. Go ahead, then.

Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040825/9e034aee/attachment.sig>