As discussed off-list with Josh, I have tried to analyse the relevance of the fields used in "resources and communication", because I couldn't clearly understand how to use them for my own projects.
First, here is a little collection of things I've seen in different projects.
Emacs: "Resource type" really describes the nature of the resource (email address, newsgroup...) without giving any information about the content and the purpose. In that case, "Audience" describes the purpose (Help, Support, Bug tracking), but
also, sometimes, the targeted audience (Developer) while a purpose could have been used (Development).
http://directory.fsf.org/wiki/Emacs#tab=Details
Gimp: "Resource type" also describes the nature of the resource, but "audience" describes the targeted audience (Developper, User support).
http://directory.fsf.org/wiki/GIMP#tab=Details
Gajim: VCS repository webview (resource type) is misused (used for Bug tracking)
http://directory.fsf.org/wiki/Gajim#tab=Details
LibreOffice: VCS repository webview is used for both "Audience" and "Resource type".
http://directory.fsf.org/wiki/LibreOffice#tab=Details
VLC:
Homepage is used to describe a URL resource type. It should be named
URL. If it really means Homepage, it is redundant with the one given in
"Overview" tab.
http://directory.fsf.org/wiki/VLC_media_player#tab=Details
The problem is that most possible values for "Resource type" don't describe its nature, but its content: Bug tracking (the nature can be URL or email), VCS repository webview (the nature should be URL).
"Audience" and "Resource type" are often mistaken for each other. Sometimes they have the same values.
There is no completion - and as a consequence no restriction - on "audience" content.
If we want to keep "Audience" as "targeted audience", it should be limited to two possible values at least (developer, user). This can be useful when the "resource type" describes only the nature (email, mailing list, newsgroup, URL).
But I believe that a field to describe the content (Bug tracking, VCS repository webview, Support, Help, Development) is really necessary. In that case, it is not necessary to describe targeted audience (bug tracking is usually
for developers and users, support is usually for users, VCS repository webview is usually for developers...)
The nature can also be useful, this is not always explicit in the URI, which is often a URL.
In the end, here is what I would personally suggest:
1) A
field "Resource" with possible values:
- Download
- Support
- Bug
tracking
- VCS repository webview
- Development discussion
- News
2) A field "Type" with possible values:
- Web
- Email
- Newsgroup
- Mailing list
- RSS
- IRC
- Jabber
- FTP
(maybe the possible values should depend on the value of the "resource" field, if it is possible...)
Here are some examples of possible combinations:
(Resource - Type - URI)
Download - Web - http://download.myproject.org/
Download - FTP - ftp://myproject.org/download/
Support - Email - address@hidden
Support - Mailing list - http://mailman.myproject.org/support/
Bug tracking - Web - http://bugzilla.myproject.org/
Bug tracking - Email - address@hidden
VCS repository webview - Web - http://git.myproject.org/
Developement discussion - Mailing list - http://mailman.myproject.org/dev/
Developement discussion - IRC - ...
Developement discussion - Jabber - ...
News - Mailing list - http://mailman.myproject.org/news/
News - RSS - http://myproject.org/news.rss
Let me know what you
think...
Cédric