On Tuesday, January 11, 2011, Cornelius Schumacher wrote: > On Tuesday 11 January 2011 Aaron J. Seigo wrote: > > anything else that should be included? any thoughts on format? > > For reference here are some proposals from a while ago: > > http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0 > > Especially a proposal for a process including how to deal with metadata: > > http://gitorious.org/~cornelius/xdg-specs/xdg-specs- > spec0/blobs/master/specifications/SpecificationProcess/specification.txt > > Not sure how much of that still is relevant, but maybe it helps in some > way.
i just (re-)read the spec process file and imho it's still 100% relevant. what we need is someone(s) from the GNOME and the KDE commuities to offer feedback on it and if/once we get to agreement on it, let's simply start putting it into practice. hopefully Vincent or another GNOME developer can aid in bringing the GNOME perspective to it? the xml format could probably use with some tweaks and a proper description of the syntax could be created as well once agreed upon. some initial thoughts: * authorinitials probably not needed? * in my initial test implemention, using UIDs from a vcard proved nice for the machine (e.g. to generate reports) but not so great for humans. :) so perhaps instead of vcard UIDs we could just put names and enforce a convention that the name as written in the xml file must match an entry in an addressbook we keep centrally somewhere. i think we can rely on people not to change their names very often ;) .. email addresses, etc. are more transient, though, and i still think we should avoid sprinkling them around in documents * the contributors section duplicates what is in the docbook formatted spec itself, so perhaps we can just drop that entirely for now. it'd be nice to have, but we can probably rip through the docbook sources to get the same information for report generation. as long as the authorship info stays in the docbook, there's really no point to duplicating the info. i would like to see clear maintainership notes in the docbook, though. * whether revhistory is needed here or not probably depends on how we handle the git repository itself. e.g. if only "release" and "patch level" versions of a spec are committed to master, then we can use git log for that instead. otherwise, i'm still in favor of the approach (as is probably completely evident by now ;) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
