Add a "maintainer" field to the "resources" in .xkan files and use it to blame the right people

Dazpoet commented 9 years ago

As was discussed here I think a maintainer field in our metadata would be amazing. Today some old files have x_maintained_by fields but these aren't really used since only people who dig through the metadata find them.

I imagine it'd look something like this:

"resources" : { "maintainer" : "Dazpoet" }

Anything added to the maintainer field would have to be a github user account for reasons specified further down.

That part should be pretty easy, I think, but the kicker here is that in an ideal world this information would be displayed to users in the clients so users know who to hassle when packaging breaks.

The problem with this solution is of course that some of us have a strong tendency to add a lot of metadata by e.g. mending broken submissions from the KS bot so we might end up with user X being the maintainer for 50 mods in a short period of time and if user X suddenly disappears we're stuck without a maintainer. Even so I think this would be better than the current system where mod authors get flak for packaging errors which aren't their fault, which in turn generate badwill.

A way to mitigate too much strain on a single user who likes to add things might be to have the field being maintainers instead and work like so:

"resources" : { "maintainers" : [ "Dazpoet", "mgsdk" ]  }

But I'm not sure you can stick arrays (that's what the things with square brackets are, right?) into the "resources" object (or w/e it's called)?

In a utopia (utopia > ideal world) the clients would have a button/command which could be issued to send an error report directly which in turn would generate a github issue report in one of the metadata repositories and pinging the maintainer(s).

Seeing as I have absolutly no clue about what limitations coding of functions like these have I'd also propose that if a user chooses to send an error report for a mod lacking a maintainers field the issue report would not ping anyone but rather add a label of the more critical variety.

mgsdk commented 9 years ago

I have no idea how we would go around getting the issues from the users onto GitHub. I guess in worst case we could make a web-interface and let a bot like netkan-bot create the issues (And autotag them?), but I don't know enough about the GitHub api to figure that one out.

dbent commented 9 years ago

The problem with this solution is of course that some of us have a strong tendency to add a lot of metadata by e.g. mending broken submissions from the KS bot so we might end up with user X being the maintainer for 50 mods in a short period of time and if user X suddenly disappears we're stuck without a maintainer. Even so I think this would be better than the current system where mod authors get flak for packaging errors which aren't their fault, which in turn generate badwill.

Because of this I would like to propose an alternative, a support object.

{
    "resources": {
        "support": {
            "mod": "https://www.example.com/",
            "ckan": "https://www.example.org/"
        }
    }
}

The support object would contain a set of URLs identified by well-known keys. The two initial would be mod which indicates where to go to receive support for the mod itself and ckan which indicates where to go to receive support for issues related to CKAN metadata/installation/etc.

Each of these could also support an array of URLs to indicate multiple locations, with the ordering of URLs within the array indicating preferential priority.

Unless specifically overridden all mods should have a support.ckan value of:

[
    "https://github.com/KSP-CKAN/CKAN/issues",
    "http://forum.kerbalspaceprogram.com/threads/100067"
]

The GitHub issues page, followed by the official forum thread. Mod authors that maintain their own CKAN metadata could override support.ckan to be whatever they want.

support.mod would typically be set to the mod's official forum thread, but may include anything else the author officially endorses as a support point.

The advantage I think this has is that it doesn't make any one particular person responsible for the mod, but instead divides it into either CKAN Team or Mod Author, which I think is much more useful from an end user perspective.

pjf commented 9 years ago

We can definitely have arrays.
Missing maintainers isn't really a problem, since we intentionally don't lock metadata to people. Maintainership is a really good way to notified of issues, either through bots or utopia buttons, but shouldn't ever stop other people from fixing things.
As an update to the spec this is relatively straightforward, although the utopia button and/or bots are more work.
I'd call this ckan_maintainer or similar, rather than just maintainer, to make it clear that the authors and ckan maintainers are different.

Dazpoet commented 9 years ago

@dbent would the support:mod antiquate what is currently homepage or how would they distinguish from eachother?

I pretty much approve of everything @dbent recommends btw :)

dbent commented 9 years ago

Would the support:mod antiquate what is currently homepage or how would they distinguish from eachother?

I don't think so. While it's rare, some mods do have proper homepages, besides a forum thread:

In fact, I would suggest that if support.mod isn't specified, the client should default to showing homepage if available in its place.

KSP-CKAN / CKAN

Add a "maintainer" field to the "resources" in .xkan files and use it to blame the right people #946