Community Mod Repository and The Majiir Challenge

[O-Doc]

Multiple concurrent projects seem like a great thing to me. If joining an existing project were really the path of least resistance, we wouldn't be seeing multiple projects come up. There are good reasons to diverge, as blizzy78 and others have already mentioned.

I agree, there's an opportunity to look at different approaches without the restriction of having to come to a full consensus prior to implementation. As long as everyone is sharing and caring I don't think we need to be stymied by a what's in and what's out feature list. It's good to keep track of what everyone wants but there will never be 100% agreement on everything. There will always be the opportunity to iterate once the prototype/s hits the proverbial shelves.

[Majiir]

There will always be the opportunity to iterate once the prototype/s hits the proverbial shelves.

That depends on how you interpret that metaphor. Some prototypes already exist, but they're not gaining much traction because it doesn't look like they faithfully implement the requirements this thread generated (or they're noticeably unpolished). I don't think it's enough to just produce a mod repository; it needs to check all the boxes, not check too many more, and wrap it all up in a package that's easy to use and deploy.

[RadGH]

I have some comments which are my own opinions, so take as much or little of these as you like...

I agree with most of your points and have updated the document. A couple of notes:

[*]I assume that in the "mod metadata" section, bold for required indicates that it's a required feature, not a required piece of metadata. In any case, this should be clarified.

I did not want to separate the same type of feature into two sections, so I included all of the metadata in the same group. They are not all must-have, but I don't think it's worth being that specific at this point.

The bold sections I did intend on being required to add a mod though. Certainly the mod name, mod version and KSP version. The summary wouldn't really be necessary, since it can use the first XX characters of the description when blank.

Of these required fields, which do you think should be optional, and why? (I'm not a modder, these kind of questions aren't obvious to me).

...I don't think Links or License are necessary metadata; there's a description box for those. Maybe some users want them... which puts it down into the Useful or later category.

I was actually thinking that it would be nice for the layout to keep links together in the sidebar. Especially keeping the donate/forum thread/source code links in a consistent location across multiple mods.

Although, I don't think we should require them, and I don't think we should have anything preventing users from adding links. So basically yeah, not a must-have. But I still want to keep it in the metadata section.

[*]Does e-mail verification really count as a release-blocking system? I wonder if there's some sort of middle ground, e.g. requiring verification in order to get subscription notification e-mails.

Well the idea was to keep it as simple as possible to get you started with the website (especially for mod developers, as they would be the most valuable members). Once you are involved we can require email verification for interaction-related features (comment/reviews/ratings/etc), or subscription notifications as you suggest.

It would be a good idea to require email notification before we can send other emails to the address as well. At this point, I'm not sure what sort of emails we will be sending out aside from subscription-related ones.

[ShadyAct]

Make a site that's supported by the important stakeholders and runs successfully for a week or two, and then we can think about getting a Squad endorsement.

And Squad's endorsement matters because there could be a link to a Squad-endorsed community solution on the KSP Launcher instead of Spaceport or Curse. Right? I'm just trying to gain a greater understanding of this.

[Esme]

It's a bit late here at the moment, so I've only lightly skimmed this thread, but this sounds like exactly what we need to offer an alternative to Curse. This gets my support!

[O-Doc]

The only thing I know they have promised the community is to do a community spotlight thread on it. That is all. I don't have any expectation that will throw additional promotion at it. It would be largely up to us to promote it through whatever channels we decide. As far as I know.

[medavox]

My last exam (final final? I have no idea about American terminology) is on Monday (0830 UTC), so I'll be fairly quiet now until after that (~1100 UTC). So I'm glad RadGH is striding forward with a public design document.

Also, O-Doc: I really like your proactive approach, unfortunately I don't know enough about any of the technologies you're using to just dive right in, without a good 20 hours learning each one first. I won't have that sort of free time to commit until mid June. However, if by any chance you need a testing platform with more control than a free host provides, then I have an old desktop (2.3GHz dual core, 2GB DDR3 RAM) running a LAMP stack, sitting behind my 10Mbps home connection. Not much, but better than nothing. If this sounds useful, let me know and I can expose some kind of access (ssh or sftp etc).

[O-Doc]

I'll welcome any help to my effort. It's not just coding that needs doing. Any help with documentation, design, copy writing, etc, is useful. The website content is one thing everyone can work on regardless of what sub project they are involved with. We need an about, faq, privacy policy, terms of use and submission guide page written up. I've had a poke at items I think should go into the terms and conditions page. That can be expanded on and fleshed out. I've also put together a draft list of categories should we go down the uploads categorisation route, my tech will be able to go either way.

[Majiir]

Of these required fields, which do you think should be optional, and why? (I'm not a modder, these kind of questions aren't obvious to me).

I misunderstood "required" to mean "must-have". Now that I understand what you were getting at, I think name and version strings should be required; KSP version should be required, but it should also default to the latest version at the time of uploading; there should always be a summary, but it would be fine if it defaulted to the first paragraph of the description. I think it would be fine if the summary were required and the description optional, and the summary is just copied (and bolded or otherwise emphasized) on the mod listing page. If Author is the same thing as Owner/Uploader, then it should be required (and this is easy) but if it's a separate field, it should be optional. The rest should all be optional or not present, I think. (In other words, I probably wouldn't change much at all of what you've listed.)

I was actually thinking that it would be nice for the layout to keep links together in the sidebar. Especially keeping the donate/forum thread/source code links in a consistent location across multiple mods.

Source control links could be great because we could integrate with various repository sites. Forum thread could be neat... I'm just on the fence about privileging certain links, especially things like donate buttons. The conservative answer is to skip them for now, since the description field can serve those purposes and they can always be added later at minimal cost.

Well the idea was to keep it as simple as possible to get you started with the website (especially for mod developers, as they would be the most valuable members). Once you are involved we can require email verification for interaction-related features (comment/reviews/ratings/etc), or subscription notifications as you suggest.

It would be a good idea to require email notification before we can send other emails to the address as well. At this point, I'm not sure what sort of emails we will be sending out aside from subscription-related ones.

I think that's all fair. Skipping validation will help get users involved quickly. We should just be mindful that validation serves a purpose. It could also help to require validation within 7 days of registration, for example.

And Squad's endorsement matters because there could be a link to a Squad-endorsed community solution on the KSP Launcher instead of Spaceport or Curse. Right? I'm just trying to gain a greater understanding of this.

Yes, but I put fairly low value on Squad's endorsement anyway. I think modder endorsement is much more important. If most of the top ten mods link to a community-operated repository, it's much more likely to succeed. Squad is icing on the cake.

[O-Doc]

Deadweasel is a total baller and downloading all the module files from Spaceport. Tomorrow I'll pull all the data attached to those modules. Between us we'll be able to put humpy dumpy back together again.

[Tiberion]

Deadweasel is a total baller and downloading all the module files from Spaceport. Tomorrow I'll pull all the data attached to those modules. Between us we'll be able to put humpy dumpy back together again.

Wholesale copying of the content from Spaceport won't fly, it will have to be on a case-by-case basis where the author has a license in place to allow redistribution. It might be a bit of a gray area for an official of the mod repository to go through and post those, it would be much better if that was a community effort separate from this project (though the repository can host them without issue as long as the licenses are in place.)

Not saying it can't happen, but the site has to be very careful to not appear cavalier with author's rights. It's something to give some thought to.

[O-Doc]

Agreed, but this way we can do a painless restore of user's data if they so desire. The data is public and there's no intention of republishing that data without the correct followup

[Virtualgenius]

If they have a forum post put it up if they dont hold it in reserve until they can be contacted

[ShadyAct]

Yes, but I put fairly low value on Squad's endorsement anyway. I think modder endorsement is much more important. If most of the top ten mods link to a community-operated repository, it's much more likely to succeed. Squad is icing on the cake.

Me too. Mostly because they think using Curse is a good idea, unless they made that announcement to indirectly put the community to work. If the repository is as successful as we'd all like it to be they'll probably endorse it on their own. If the repository succeeded and Squad continued to run the Curse site, but modders ignored it, do you think new users would be confused or distracted by it at all?

Deadweasel is a total baller and downloading all the module files from Spaceport. Tomorrow I'll pull all the data attached to those modules. Between us we'll be able to put humpy dumpy back together again.

It sounds like you don't need help with that to me but if you do I'm willing to lend a hand. If you can bear with me being a bit cheeky, what's a humpy dumpy? It sounds like something that would violate the TOS.

Edited May 11, 2014 by ShadyAct

[Majiir]

If the repository succeeded and Squad continued to run the Curse site, but modders ignored it...

I don't see how the boldface events are compatible.

[ShadyAct]

I don't see how the boldface events are compatible.

"If the repository succeeded and Squad continued to run the Curse site, but modders ignored the Curse site ... " would have been clearer, but I felt that would make the sentence redundant. I wasn't trying to say a mod repository could succeed without anyone putting mods on it.

Edited May 11, 2014 by ShadyAct

[O-Doc]

It sounds like you don't need help with that to me but if you do I'm willing to lend a hand. If you can bear with me being a bit cheeky, what's a humpy dumpy? It sounds like something that would violate the TOS.

Deadweasel now has a copy of the entire Spaceport website so on he 30th it won't be lost forever. Today I'm rebuilding the database so that all content will work within a new website. My current plan is to have a recover module widget where you will be able to browse Spaceport metadata and make a request to recover your module on the new site.

Some have pointed out there are legal issues involved but, I'm sure if all parties demonstrate good faith that those issues can be reconciled to allow any community website to supply this recovery functionality.

You can always help. One thing we need is a description of what the recovery widget will look like, what data is displayed and what a good process should be to do a module recovery.

Edited May 11, 2014 by O-Doc

[Tiberion]

I really have to question what value that has. It seems destined to serve as an engine for third parties to browse spaceport data and find an out of date mod they want to post to the new site without much validation.

To begin with, there isn't much metadata you can gather from the public side of a spaceport mod page. Version numbers, license information, forum links, descriptions are all going to be in a big mass of text in the main text field with no consistent format.

Also, while you can gather the author name, there's no way to verify that against the identity of the user on your end. So that means the whole transaction from end to end is based on the "good faith" assumption that the person doing this has the rights. I don't think you can operate on that assumption. There are lots of jerks out there, and even if we exclude people who did it maliciously, there are plenty of others who don't even understand the concept of a license and would use it out of ignorance.

I think that any active authors can move their work easily manually, there's literally not much to transfer from Spaceport other than the file (which they will have) and it should be done quickly if the site is adopted widely.

For inactive projects that have the proper license to allow re-posting and that are still relevant and functional in game, it will take a little longer as interested parties sort through the process, but that hardly needs to be automated.

For inactive projects that do not have the proper license, those can't be on the site. There's no way to transfer hosting permissions from Spaceport to the new site without a license or author consent.

Having the files backed up for posterity is a good thing, especially if the 2nd group there doesn't have them elsewhere. But automated porting seems like work without the possibility of much (positive) return.

[RadGH]

I would like to point out the alternative to hosting other people's mods (without consent), which I mentioned in my Google design doc.

Rather than hosting the mod files and trying to recover data, you could simply add the mod on your site and link the download button to the mod thread. of course, when ksport dies the links on the forum will need updated by the modders.

But you assume they will upload them somewhere, hopefully on your site, if they don't already have an alternate mirror.

This would avoid legal conflict of hosting files without permission. Although it is perhaps not the best solution, it is the most realistic option without breaking any rules.

If your mod site does not have the mod I'm looking for when I search, I will leave and search elsewhere. It's better to at least have the info available.

[O-Doc]

But automated porting seems like work without the possibility of much (positive) return.

While I was reading this I was formulating in my head a point by point rebuttal but, then I got to this last sentence which pretty much sums up the difference in our worldview so, no other response is required.

[Tiberion]

While I was reading this I was formulating in my head a point by point rebuttal but, then I got to this last sentence which pretty much sums up the difference in our worldview so, no other response is required.

Such is your right, but without stating your reasons no one will know why you find fault with the statement.

I think part of our misunderstanding might come from a different viewpoint of any site's purpose. I am working off of the assumption that it is a mod repository, a resource for mod authors to host their work in a convenient place for the users. You seem to be (from what I read here and in the Curse thread) working off the assumption that it is a mod index site which tries to link all possible mods for mod users.

They share technical aspects and data, but they don't have the same goals.

[RadGH]

working off the assumption that it is a mod index site which tries to link all possible mods for mod users.

I think it needs to be some of both, at least initially. People won't use it if there are only a small selection of mods available. Especially if they are new to mods and are looking to set up a modpack like Scott Manley has. Whichever site makes it easiest to obtain all of the mods in one place wins.

This is one of the reasons why building a successful community repository is at such a huge disadvantage. If Squad's partnered up with Curse, they certainly aren't going to promote a community site.

To be successful, it would require mod developers to boycott the Curse repository. In doing so, they lose out on players who are following the link Squad offers from their games.

So really, Squad is the greatest enemy here. Which is weird, because they're usually the good guys.

[Tiberion]

I think it needs to be some of both, at least initially. People won't use it if there are only a small selection of mods available. Especially if they are new to mods and are looking to set up a modpack like Scott Manley has. Whichever site makes it easiest to obtain all of the mods in one place wins.

I disagree. If the site is good and backed by people of reputation within the community, mod authors will use it. It won't be that hard to be better than CurseForge.

If mod authors use it, people will go there for mod downloads. The forums are still the primary way to publicize mods, we aren't relying on a repository site to draw in new users, though that will happen naturally as the site gathers content.

Any wholesale import of data from Spaceport, by Curse or by this repository seems untenable. The rights to do it simply don't exist, and the rights of the author must come first. Break that rule and any repository is already doomed to fail.

Edited May 11, 2014 by Tiberion

[O-Doc]

Such is your right, but without stating your reasons no one will know why you find fault with the statement.

I think part of our misunderstanding might come from a different viewpoint of any site's purpose. I am working off of the assumption that it is a mod repository, a resource for mod authors to host their work in a convenient place for the users. You seem to be (from what I read here and in the Curse thread) working off the assumption that it is a mod index site which tries to link all possible mods for mod users.

They share technical aspects and data, but they don't have the same goals.

Maybe you should download my docs zip file and look at the database specs and the sample repositries. The site I'm developing will allow you to hold your module onsite, in mirror, or both. Full versioning, internal build version management, contributor management, community reporting/moderation, etc.

Of course, the non-fact checked hearsay of what I'm doing is also entertaining. Particularly when I'm providing full transparency on the build.

[Tiberion]

What are you even talking about? I never even referenced your database schema in passing, I am referring to your proposal to shoehorn the expiring Spaceport data into the repository.

And honestly, dial it back a notch, you aren't going to convince people to work with you by browbeating them.