developer url tag in appdata

[hsitter]

Along a similar note as #155 the existing appdata does poorly in specifying ways in which to onboard users as contributors (except for maybe the translate url type)

To aid in turning users into contributors it may be interesting to provide urls to dev resources. To easily distinguish them from regular URLs I'd put them in a <developer> tag:

• homepage (dev landing page; could be a dev wiki for example)
• chat (IRC/gitter etc)
• mailing list
• VCS browser (e.g. github repo page)
• maybe actual VCS URLs (git repo; hg repo; etc. may be tricky to properly support this so perhaps only provide a VCS browser url instead)

[ximion]

@hughsie What do you think on adding a block of URL types specifically for developer interested in the application?

So far, we expected the project sites to set up a developer "landing" page and link to their resources from there.

[aleixpol]

Somewhat related to #125 (if not duplicate).

[hughsie]

I'm happy adding more types, although I'm not sure how we'd use them in gnome-software...

[ximion]

I am not generally opposed to adding more URL types, because they are very cheap to add. I do have a few concerns though:

• New URL types must be used - we should not add new types for a specific purpose that sound nice in theory but will never actually be displayed by anything.
• New URL types should be generic - adding some that are specific to a project or a specific workflow should really not be added to AppStream and instead be in a custom value in a <custom/> tag
• Any new URL type must have a crystal clear definition of when and how it should be used. E.g. in terms of mailinglists, where should we actually link to?

I see problems with "chat" URLs, because I don't want to encode certain tools/vendors in the URL. But if that is not done, there can be only one "chat" URL, in which case it isn't clear where to link to.
Maybe for this case a more general "contribute" URL makes sense, to point to a webpage where the developers can list ways to contribute to the project and contact them, e.g. by linking to mailinglists and IRC channels.

For VCS URLs, we can't use the <url/> tag, because that tag is really for user-facing webpages by its definition. Maybe we could add that information at some point, but if so, then as a new tag (<vcs type="git">https://...</vcs> or similar).

I think adding a separate new <developer/> tag to put URLs under makes things needlessly complicated. I think we can expect the frontend to pass judgment on which URLs are for developer and if and where they should be shown.

[cassidyjames]

Something we've discussed doing in elementary AppCenter is having a store-wide developer/author/project page. So if one author published three apps, there would be a page where it compiled all of those apps and included some extra information about the developer.

elementary/appcenter#148

The problem I see with that in combination with component-level developer data is that you'd have several pieces of possibly-differing developer data from each component. You'd have to deduplicate the matching ones and figure out how to display the conflicting ones, which sounds like a technical and UX mess. 😄

So while it may or may not make sense to have some extra information about a developer on a specific app listing, I guess I would just say keep in mind other more interesting implementations of appstream data as well.