Re: GDP Editors

> I'm all for having a gnome editorial team.  However, I'd like to see it
> in a form similar to the UI hitlist, as I think that that is a good
> format for this.  

I'm not sure if I completely understand what you mean by the similarity to
the UI hitlist.  Are you suggesting that we need a "Documentation Hit
List" which goes through existing documentation and finds places where the
document layout or presentation can be overhauled?

I see this as an additional task to the basic process of: author writes
documentation, gives it to the editor for corrections/feedback, then the
document is fixed and sent to the packager/developer for inclusion.

So, I would suggest that the documentation hit list be divided from the
editors, since their objectives and tasks are really quite different.

At the risk of talking about something I know almost nothing about, and
also offending people, I wonder if combining these two tasks might be a
shortcoming of the UI Project.  While the UI hitlist appears to be doing
great work on a small group of applications, (to my knowledge) most
applications do not benefit from the UI Project. For example, as far as I
know there are no UI guidelines that an application author can use when
creating his UI.  Nor is there a UI "editor" that an application author
can ask "check out my program and tell me if I've done anything blatantly

(If I'm wrong on these facts, please tell me.  I mean this to be a
constructive criticism.)

> In addition, it'd be extremely cool if they didn't
> limit their scope to the docbook code, but looked at the text in the
> actual applications.  Most developers aren't grammar experts, and can get
> very creative when writing error messages/dialogs/labels etc, and many
> apps could use a once over.

Yes. I agree. Is this the job of the editors or the general documentation


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]