Quack! If we tried to make a Bugzilla query for documentation components easier > (ignoring the "documentation" keyword), a first step might be to reduce > the number of different names for the same component. > > Below is a quick and dirty list. > - need to remove those projects where GNOME documentation team does > not maintain the documentation instead of the project developers > (sounds like a candidate for quick Etherpad editing at Hackfest) >
I did a similar one for projects.gnome.org to round up those git repositories which haven't seen a commit in 2 years/generally not being actively maintained. [1]. If a project does not use yelp-tools and is not a GNOME 3 app yet then what is the resolution? Should we consult the maintainers to see if they are going to port to GNOME3 and thus are willing to use yelp-tools? For example: https://bugzilla.gnome.org/show_bug.cgi?id=698497 > - need to remove projects which are dead / unmaintained because we > don't care (I might have a script somewhere left for that I think) > Wouldn't this make bugzilla out of sync with projects.gnome.org or even git.gnome.org? Say if the project doesn't exist on bugzilla.gnome.org but its source is available on git.gnome.org. - need guidelines for project maintainers on component naming (though > they might be ignored of course) as maintainers can create > components themselves in our Bugzilla setup > > - wondering whether something like "Dev Docs" vs "User Docs" might > make sense (but that would mean a large renaming, plus people might > search for the term "Doc..." in the component list?) > +1 and auto create these for new projects on bugzilla on behalf of maintainers/ developers? Cheers! -Sindhu [1] https://docs.google.com/document/d/1XDgzLrXAKHC55rGnFUXw0xoP8f6bMArNyRzcvsZ5cSo/edit
_______________________________________________ gnome-doc-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-doc-list
