Opt In / Opt Out | Required changes to CKAN. #1793
Comments
|
The representations made by the first part of that post are inappropriate, and false. (edit) Ahh good. I see he edited it. |
|
You mean the part I changed after having noticed I made a mistake? |
|
I like the greyed out idea as an additional feature |
The only problem with this approach is the number of cases where authors don't care if their mods are on CKAN, but don't feel like managing it themselves. As far as opt-in/out/list goes, I think it might be better implemented as: Supported: The author(s) of this mod officially support installing through CKAN-based installs. Available: This mod is available for CKAN-based installs. There is no statement of support (in either direction) by the mod author. This is the default for all mods that don't explicitly state a policy. Unsupported: This mod is available for CKAN-based installs, but the authors will not provide support for them. Prohibited: This mod is not allowed to be installed via CKAN. External: This mod is only available for CKAN-based installs when using a separate repository. (A pointer to the new repository should be in the metadata). With the above in mind, here's how I think this can be fixed:
|
@VasVadum @pjf explaiend all this stuff very well in #1078 IMHO This whole discussion about opt-out is pointless (and not motivated from legal standpoint). Mods authors should learn how to use licenses properly.
No, it will not. Few moders will sentece their mods to disappear in future, oh well. ARR mods will disappear sooner or later, that's why I don't use it. There is plenty FOSS mods. |
|
any mod i make has been changed to ARR until ckan respects modders legally speaking ckan crosses into the same territory has torrents, i have no issue with how ckan software itself works, i have no issue with ckan auto fetching mods / having an opt-out if a modder decides ckan is an issue to him. what i do have issue with is those who run ckan having policy to abuse "what they can legally do" without respect to mod authors. i disagree with ARR whole heartedly, thinking it's rude to the community, as ARR blocks other mod authors from learning / using / expanding upon what i (or other authors) learned / expanded upon from the community in the first place, and yet its the only option i see when disrespect is purposely given by a few in the community. add at least as far as "de-list mod no questions asked", and - just given the past disrespect in policies - a policy to not re list if author had it removed. i like what ckan does, i accept bugs in software, i dont have to accept disrespect towards myself or others in the community. |
|
I like how zealously you keep doing all your best to keep all the FOSS mods listed on here tho ;) |
Torrents involve distributing (possibly-)ARR content that you do not have a license to distribute. CKAN does not handle the actual distribution of mods, it only points at a source that is (presumably) authorized to do so. Even in the case of an ARR license, CKAN is still only deep-linking to your content -- a practice that -- while controversial, has generally been ruled legal in various jurisdictions[1][2][3]. So ARR does not solve this issue at all (though it was a valid option in cases of e.g. the 64-bit debacle)
To clarify, you have no technical issue with CKAN; the problem is more one of policy and the human factor? (This is not an attempt to derail the discussion or diminish its importance, just an important distinction that I think needs to be made.) Technology is rarely the solution to what is -- at its core -- a human problem. We can come up with a technical solution to aid in implementing and abiding by some set policy, but technology cannot replace policy as a whole. My earlier post, for instance, only holds weight if CKAN contributors actually abide by the intent of the policy definitions specified. I'm personally of the mind that a complete and total opt-out of CKAN is harmful to everyone:
If authors have the ability to restrict CKAN solely to update checking (as opposed to delisting entirely), it mitigates most of these issues. [1] https://apps.americanbar.org/litigation/committees/intellectual/news_0209.html |
|
After reading forum I think I underestimated scale of problem. It's sad that good tool becoming a threat because of users that can't read and spam modders with CKAN issues :> |
|
@dewiniaid first off, torrents are do nothing more than ckan, a torrent is the equiv of ckan meta, instructions on where to find the file, information on the file, etc. what ckan does is go a step further, accually handling distro of the file itself. it does not host it, but it does aquire it and deliver it, which falls under distribution. if you goto the corner drug dealer, distributes drugs, taking them from a higher dealer and delivering them to you. yes ckan itself uses code to deliver to you. that is why earlier (before bit torrent protocol) programs got hauled into court, the user was hosting the file, but the program (and sole reader of "meta data" was downloading and delivering the files. torrenting nowadays has the niche they dont accually download / distribute the file, as they don't touch the file. 2nd yes, my issue is the human factor and disrespect that standing policies have towards the community. disrespect drives authors away, which hurts the community far more then having to manually click the download link on forum post, and unzipping that said, ckan has made no effort to lessen that burden aside from full auto install, which granted is a noble goal, but software will always have bugs, and lessening the burden of manual install (buttons to open appropriate folders without navigating, etc is the simple minimum step) can be nearly as good |
This is the only suggestion I take issue with. Mod authors shouldn't have the authority to dictate what tool a user can use to install their mods. Don't support it, fine. Don't be willing to troubleshoot installs made with it, fine. Don't want it automatically listed? Absolutely fine. But this is over-reach in the extreme. If CKAN supports it and a user wants to install a mod directly so they can use CKAN to manage it, why shouldn't they be able to? Seriously how would anyone expect people to react if in other communities like the ones around Bethesda's games had mod authors suddenly saying "Oh no, you're not allowed to use Mod Organizer to install this one! You have to use NMM!" (Or any other particular mod tool.) I don't see that particular change in anyone's best interest. At best it's going to lead to annoyed users who will just pester the mod authors more asking why they would do such a thing. I fully support every single other suggestion in that post. I myself brought up similar suggestions on the KSP forums not long ago, but I'm pretty sure they got lost in the animosity mod authors (or at least a vocal few of them) have expressed at CKAN as a whole. Ferram et al. made it abundantly clear on the forums that suggestions like this to mitigate the issues they're experiencing aren't acceptable to them. But again, I'll reiterate my support of this, sans prohibiting installs. It would provide more information to users and hopefully direct them to the right support areas instead of pestering mod authors with issues that are actually with CKAN itself. (Basically I would hope to see users directed to CKAN's support pages first for Available, Unsupported, or External installs. Sending them to a link for common troubleshooting steps here on the GitHub wiki would probably help redirect users to the right spot.)
That's why I personally think having a way to use CKAN to direct users to the right place for support would be very beneficial to all concerned. |
A torrent has a source (or many fragments of a source) somewhere, and the people responsible for said sources (e.g. someone else running a client) are not authorized to distribute the content. In the case of CKAN metadata, the source of the data is the author's own website/Spacedock/Github Releases/Curseforge/etc; linking to that source is perfectly legal. I'm not infringing on copyright by linking to, say, one of the early releases of KSP on Squad's own website, but if I link to the exact same file on freepiratedsoftware.example.com I'm potentially participating in "contributory infringement" (the same way various torrent sites have been shut down), and the owner of said site (where the actual data lives) is definitely infringing. Never mind that it's a free download, the ARR license means "Hey, only I have the rights to distribute it." |
|
@Cphoenix "Prohibited" is intended to serve as a way for an author to explicitly say "No, I don't support CKAN at all, please install my mods using my preferred distribution method(s)." There is no technical way to actually enforce it (aside from DRM of some kind, and nobody wants that), but the intent is that the author's preference is made very clear and cannot be disregarded by means of "user is conditioned to just click OK without reading the prompt". I don't like it either, but it seems it a necessary option. Remember that one of the issues here is that various things -- from CKAN metadata breaking an install to "Your mod doesn't work" "Did you read the install instructions and edit the .cfg files?" have led to an increased support load for several mod authors. There has to be some way for them to go "Nope, can't/won't handle that" -- the lack of that option is the crux of the current issue. That said, I still feel the best possible result is to expand the options that CKAN metadata has in such a way where delisting/"Prohibited" becomes the option of last resort in these circumstances, rather than the only option. |
|
@Cphoenix It's not a matter of legal standing, it's a matter of common sense. If a modder asks you to remove your listing as a matter of courtesy, you should do it, otherwise they're likely to come back with an ARR licensed mod, and ARR mods are a pain in the ass for everyone involved. |
|
From my perspective it looks as simple as adding a mandatory "maintainer"-field (obsoleting "x_maintained_by") analog to "author" and adding a field "manual_install" set to true for mods that must not be auto-installed. |
|
"torrenting nowadays has the niche they dont accually download / distribute the file, as they don't touch the file." torrent sites only host metadata. torrent clients actually do file distribution of the bits that they download. that is where it gets legally a bit grey. ckan's github site only hosts metadata. the ckan clients themselves do absolutely no distribution of the bits that they download (other than delivery to the end user running the client -- pulling from the publicly available URL that the author of the mod has made publicly available). legally i don't see how it could be more clear that this is a "deep linking" issue vs. a "bittorrent" issue. ckan clients do not deliver bits to other ckan clients. ckan is not bittorrent. |
|
if mod authors want to control their own distribution, they could introduce a similar scheme to the way that oracle requires a time-sensitive cookie to download java, requiring users to click through the EULA. |
|
Nothing could stop authors from moving their files (invalidating the CKAN-download-URLs) and relicensing them with the same conditions plus "CKAN-Exception" stating installation via CKAN client is forbidden. (Not making them ARR this way.) |
|
fun fact, majority of torrenting is 100% legal, most MMOs use it to lower the server load, lets get that bit out of the way before someone claims its all bad - the bad bit is the places that decide to share stuff they arent allowed to, and ofc the media will fuel any fire that gets em ratings, nobody cares "this guy did nothing bad today, neither did this guy" @janbrohl many licenses can't be changed from what they are now. and ckan policy as stated in another issue, is if permission is given it stays given - edit: clearly noting if alternate downloads of the mod exist, switch to them |
|
@Cphoenix improving the backend to cover more usage cases and minimize the number of errors is all well and good but these issues have been known for over a year and instead of fixing them this project seems to have instead prioritized keeping up with the metadata. As a result what the authors want is a way out NOW with the option to come back when the service improves LATER. simply put there is no confidence that the needed code changes will be made in a timely manner. |
|
I think we've gotten off-topic here. No mod author has ever stated that indexing mods is against the law (regardless of license), and discussions about that are pointless anyway. Although the fact that arguments seem to be heading towards an implicit "we should index ARR mods regardless of modder opt-in/opt-out too, it's legal just like for torrents!" has me concerned for the resulting workload. My main concern is that CKAN's policies are set up so that create more support requests for me, and then provide little option to protect myself or to convince CKAN to change those policies. Because of these policies, I have no confidence that CKAN and its contributors can be persuaded to implement proactive error checking methods or whatever else may be needed to reduce modder workload in a timely manner, considering they have the option of simply doing nothing and the mod remaining listed. For context, about a year ago CKAN created a gigantic support nightmare for a FAR release due to a metadata error (actually, several of them back-to-back), burying crucial bug reports that I needed to fix actual critical bugs in the mod. The "no courtesy de-list" policy was officially adopted a month later. An issue to address the cause of the FAR debacle only got created in April. No progress has been done on it since. As of right now, there are a lot of modders that are very ticked off because they have no simple means to deal with the consequences of CKAN's errors. The extent of those we have are to license more restrictively (at least for now), to put in the effort to manage the metadata ourselves (though given the recent happenings with @BobPalmer even that isn't a guaranteed fix) or to simply quit modding. This is not a healthy situation that could easily be addressed through changes to CKAN policies. |
|
The problem that I see is that a "Opt-in only" policy means a lot of mods would never be listed on CKAN through author apathy. I would like to find out how satisfactory it would be to change the policy to allow open licensed mod authors to opt-out from CKAN installations, so that CKAN is not pushing authors to switch to restricted licenses? This seems to me to be a simple policy change that would allow us to quickly lower the level of antagonism in the debate. Any technical solution for listing mods for user tracking without CKAN installation is going to take time. Time during which the current situation is maintained, and mod authors are getting angrier and angrier. So I propose a change in CKAN de-indexing policy to say that open licensed mod authors can opt-out of CKAN installation. Initially, this would effectively mean opting out of CKAN listing entirely, until CKAN has a system in place for listing mods with no installation. @ferram4 , @BobPalmer @anxcon, @Sigma88 , could you please respond to this specific suggestion? |
|
I'd like to cover that suggestion, also toss out a total of three (IMO reasonable) things that can sort at least the concerns on my end. Yes, the option to opt out regardless of licensing and be absent from any listing (even just the mod name, though I doubt many would do that, I do see some cases where a mod goes on hiatus, or has been deprecated (how long was Regolith in CKAN?), etc.). A staging area (as suggested before) so that pull requests are vetted. So anyone messing with FAR, or adding one of my mods. or even the case where I fat-finger my own metadata. Make sure it at least passes some cursory checks. This ties into the next point (which again - helps everyone). I agree with @politas on modder apathy. I also expect that 95% of the modders are fine with their stuff magically appearing. But we also want to make sure we handle the few edge cases. A new mod comes up. Ask said modder 'We are planning on listing this... let us know if you are not ok with this'. Wait 48 hours (or whatever). If no response, put it up. Done. If they say 'no thanks', respect that and move on. If modder comes back later and says 'please take it down', do so. In all cases, there's a conversation that takes place. The wishes of content creators are respected, but CKAN is not stuck having to chase down every modder getting explicit permission, An answer may also be 'please don't ever list any of my things - I will sort them myself'. Plunk that author on a list. This is an easy gate to check in pre-staging. Ferram may prefer to vet his changes himself. I may prefer to do my own metadata, or not list all of my mods. 95% of everyone else may be fine with the default system. I think the changes below sort it for most everyone (though I cannot speak for @ferram4, @anxcon , and @Sigma88 To recap. Ask first. If no reply, go ahead and list it. I respect that the last may take time, so steps 1 and 2 are a good start. Tho I think step 3 is pretty important to help alleviate the frustration. |
|
@BobPalmer , can you expand on what you believe is the minimum acceptable level of vetting? What checks should be carried out? |
|
@politas - At a minimum - make sure the file is valid, and that the dependencies are there / respected. Check against authors known to publish their own metadata, or who want a chance to review the netkan before it changes. Pie in the sky would be to have maintainers who would actually check the CKAN download first and make sure KSP loads, etc. before giving the thumbs up. That last one is of course an edge case - relevant to things with complex dependency paths or very compex installs (like RSS, etc.). Me, I'd be happy knowing that my Netkan gets a spot check, and that if a netkan slips in where someone accidentally submits one of my mods, it can get caught and someone can ask me before it pops into the index. |
|
Another good example will be when we have the bruhaha post release where everything gets messed up due to incompatible versions. A quick 'is this compatible with the new version? Mind if we set that to push other mods through?' goes a long way. |
|
Another issue is the lack of clear APIs for dependencies. CKAN by default assumes that dependencies are not version-specific, and that assumption has messed up CKAN installations of FAR releases. We probably need to disable automatic metadata updating in such cases and switch to vetting each new version. It's a pain in the arse, but that would make things better for CKAN users and affected modders both. |
|
Agreed, but good news is that will be an edge case. If a modder sees something blow up, they can always de-list and have the conversation on what steps need to happen to sort that - including a manual or joint vetting process. i.e. if mod X has some weird issues, agree that it stays in staging until either the modder or a designated maintainer can vet it out. |
For explicit opt-in from SpaceDock and the like, I'd say give it 24hrs or so just to be safe before it gets pushed to the release repo/branch (that's more of a wishy-washy "eh, seems okay" bit regarding the 24hrs; I pulled that out of my...you know). Longer if there is some confusion about what the metadata should say (see#KSP-CKAN/NetKAN#4149 for an example), obviously. @BobPalmer is right I think that it's more the process that matters, not the timeframe. We can probably just settle for whatever is "close enough ish sorta" for time. |
|
TL:DR. Staging area yes but not as we know it. Something else is brewing. After a bit of digging around through my notes.... The stage area idea is correct way to do it but it is also overkill. Initial suggested reason only applies to a few mods. Plus in some edge cases that will not fix some of problems we are seeing. It is possible to submit metadata and have it pass all checks. Even the best of us will not see an error. Then things still go wrong in a tiny number of cases. None the less. We need a staging area anyway. See #1679. Some of this could be bashed out of existing code. Although that is a huge guess on my part. We kind of already have a way to do this but I need more time research the idea. In short we mark as incompatible and require Also .... The op out policy sometimes needs to be though of as an emergency stop button / debugging tool. Recently I have seen mistakes where metadata is correct and we get temporary problems. Nothing too bad really. This may have been acceptable in the past but numbers of forum users has grown. To the point where a minor problem causes too much spam. Those issues have be captured where we need to fix something. A quick example Mod A depends on Mod B. Both sets of data good. Thumbs up. However fails because we forgot Mod B depends on Mod C. Turns out C is out of date. That's the simple version of the story. If you want to dive deeper into the actual bug report see #1646. Now lets be clear this does not current effect USI mods. As far as I am aware. However it may affect others in the future. So the issue is still alive. At the time this one happened @BobPalmer got error reports. We did not know what was happening. It was pain to tell people just to stop and give us time to investigate the problem. Now an opt out might be overkill here but it nice to know there is a "panic button" procedure when the forum starts to go nuts. There is also another reason for opt out. Here is the controversial part. Sometimes it has nothing to do with CKAN at all. However we can't sit back do nothing. Sometimes we going to have to delist the mod anyway. Just give us time to think the problem through. Or talk to the mod author through solutions. No I am not going to write an example. It would look like a witch hunt. To error is human. To forgive is just good PR policy. If a mod author calls for it lets accept by default and then try to help resolve the problem. |
|
Sorry, had trouble following all of that. But I'll reinforce my preference for a basic staging process - it solves a lot of woes. There have absolutely been cases where I wish this was handy. RE opt out - IMO the policy is in a good place. An option that is on the table, no questions asked, for any modder that desires it. Conversations should of course take place, but there are going to be people who do not wish to have a mod be a part of the indexing at this time. And yes, it's also a nice 'kill switch' that lets people withdraw until said conversations take place. For Explicit opt-in (think SpaceDock) I can go either way - immediate listing into staging or not, and trust the team will make the right call on that specific process (and we can always adjust if people get grouchy). |
|
In terms of specifics, I assume the best option here is just to add two branches to KSP-CKAN/NetKAN called say "staging" and "experimental"? (Having entirely different repos would be needlessly complicated and overkill. Also for anyone interested, this is the workflow that would be required from the people with write access to the NetKAN repo.) |
|
Well no, it wouldnt be overkill. Just have one repo (experimental) use NetKAN as now, with NetKAN submissions from everyone, screened by the Maintainer for the relevant mod, while the other repo uses only .ckan files that have been declared stable by the Maintainer. |
|
The reason I say it's overkill and complicated is because it would involve splitting the relevant history of each edit among different repos. That means no one would be able to get a complete picture of how new .netkans were added and eventually committed to the master branch without looking at two distinct repos. It'd add a lot of overhead for maintainers. Edit: An (sorta) alternative workflow is just to cherry-pick commits from staging into a new branch, and then merge that into master. Would probably be a little clearer what's going on that way. |
|
.netkans would not BE added to the master branch of the stable repository. The stable respository would consist only of .ckan files already confirmed, by usage and testing either by the modder or maintainer, to work properly, having been generated and tested on the experimental repo, which would have the .netkan files and its generated .ckan files. |
|
I hate to interrupt again with a question. Why can't we do this on the local client? The reason I am asking is the following may help. I admit it has nothing to do with staging. I know that. However it sounds like staging to me. It can provide the same function. Plus we already have done a lot of the work. Although it needs tons more work. Here goes. Right now. I can simply switch off the metadata version controls. To do so requires at the minimum. Knowledge of the system and use of the CMI. The normal GUI does not allow it. So I can do stuff that most people can't. In effect sometimes. I get access to mods before anyone else gets them. Anybody can do that. If fact we had a massive debate on how to control this. Right now it is not fully enabled as far as I am aware. The key point is some get to install mods in CKAN that others can't. I am guessing there is only a few in relation to the general population of users. I am guessing that perhaps because they had to jump through technical hoops. They hopefully don't send mod authors crap bug reports. Once that population users is happy. When there is no install bug reports coming back. We then do a minor automated update. Say in the Here is another way of looking at it. Mods did not actually get deleted. They just got hidden in a place that a tiny number of people know how to access. Is any of this relevant. If not that is ok. I can bugger off and try again. If it has got some use then I could do more research in this direction. |
|
I have another question. On the staging issue. We should be pushing the conversation to #1679. Just so @techman83 sees it in one place. There is also a nice definition of overkill there and how traditional staging is difficult to do. Back on topic here. I thing we a now all agree that the policy on on opt out is correct. If mod authors have objections to CKAN we need to respect that. Details are irrelevant. It just the right thing do. it does not have to a permanent decision. We can switch it on and off. I think there been a convincing demonstration of this recently. If there is any way to improve on the methods used to delist at will. Or sort out any other grievances. I sure the CKAN team want to listen. |
|
You think incorrectly, there. For certain conventional values of 'we', anyway. |
|
I am only too painful aware of this and was trying to be diplomatic. I apologize if any offense was caused. Lets be honest here. I am not in any special privileged position here. I am just once guy that reads everyone's side of the story. I am trying to understand the majority whilst not ignoring the minority. Oh course the words majority and minority are personally subjective. Here is a bit of information that might change perceptions. I am disliexic disaletic dissalictic.... Oh sod it you all get the point. If I use the wrong words I am sorry. |
Thanks for that; I really have to stop posting things after I've done a bunch of overtime that day. My brain gets all mushy and forgets stuff. >.< |
|
For whatever communications are to happen between a mod's maintainer and the CKAN indexing team (disallow CKAN install, provide maintainer's metadata to override CKAN repo's metadata), may I suggest that a comparable additional mechanism is provided to communicate the same info inside the mod package itself (e.g. in KSP-AVC format), because:
|
|
This method is already in use, and deemed not useful enough by modders. |
|
@Blu3wolf - as in, there's already a way to specify, within a mod's own files, that CKAN should not install it, and CKAN already respects this setting where found? [Edit - did you mean via a metanetkan? If I've understood them right, a metanetkan is still an item at the CKAN end, under the CKAN team's control; a mod maintainer wishing to opt out needs to alter something at the CKAN end - yes, as a one-off (barring errors) - and I can see why this might be not useful enough. I'm thinking more along the lines of a netkan in the mod package, if present, being the primary and compulsory netkan even if the CKAN repo netkan is not a metanetkan. A mod maintainer suddenly wishing to opt out could do so by adding a netkan to their own mod package as rapidly (or as slowly) as they like, not dependent on the availability and response time of any CKAN maintainers.] |
|
Put two conflicting .version files in the mod release. If the .netkan (like most of them) uses the avc file for versioning, it wont know what to make of it. |
|
That would be treated as a bug to work around, not a signal. |
Very much agreed. The whole point of these discussions is to come-up with a system that works for modders as well as users (and the middlemen maintainers). Having to intentionally break the .ckan-generating bot to communicate anything to the CKAN team will just end in misery. 😢 Besides eventually someone on the CKAN team is going to think "Why the heck isn't the versioning working? Sod it, I'll do it myself." (Forgetting to check if there are two version files, or not seeing that there are two, etc.) Not ideal. |
ayan4m1
changed the title
ayan4m1
added
Policy
|
@politas it might be worth updating the https://github.com/KSP-CKAN/CKAN/blob/master/policy/de-indexing.md file now that policy has stabilised. At present, the file contradicts itself - perhaps it would be clearer if the policy simply said that mods will be removed at the users request? |
|
We've been running with the policy changes for over a year now with no further complaints from mod authors. I'm going to close this issue off now. |
|
Then I will forward a PR to clarify the policy file - it currently presents two contradictory policies in the same document and asserts that both are the position taken by the CKAN leadership. |
and others
CKAN has officially become a threat to the community because mod author are beginning to change their mods over to All Rights Reserved in order to stop CKAN from listing. This will hurt modding in the long run, and cause potentially permanent damage if this ARR trend kicks on just to get back at CKAN for not allowing choice.
You need to change your de-listing policy immediately because I will not continue to support something that is going to ignore this immediate threat. It has been stated that when CKAN becomes opt in, most of this issue will go away and the people who are angry and wanted to de-list, are likely to no longer want to de-list.
So here is MY personal suggestion which is slightly getting some negative opinions against but I still think it is good for de-listed mods to help us manage everything in one place;
If an author de-lists, you can grey their mod out in the program and still show the home page for users to click and go get the mod manually, also showing a version number on it and all that jazz. Instead of checkboxes or dashs where you would click to auto install/update a mod, place an X for a delisted mod. When a mod has an update, turn the "update" column X into a clickable button which brings you to the home page of the mod so that you can find the download URL. Make sure to make a note however for de-listed mods when a user clicks a home page button in one for the first time or an update button on one for the first time that it pops up an un-closable message that lasts for a minimum of 5 seconds;
The author has requested that his or her mod not be downloadable via CKAN, so you must do this via his or her page. Please do not pester the mod author to change their listing status, it was their choice to make and they made it for whatever their reason was and they are even less likely to change their mind if people spam them with requests to list on CKAN.This way I don't need to manage mods via browser bookmark folder, and can still find a mod via CKAN even if I can't install it via CKAN. I think an even better option for this though, is three versions of opt.
Opt-In: Your mod is listed and downloadable via CKAN.
Opt-List: Your mod is listed in CKAN but not downloadable. It can still notify of updates too.
Opt-Out: Your mod is not listed in CKAN unless it is detected in your game install, and then it is marked red in CKAN with only the information found in the meta-data that the author has provided with his mod. (Or don't list at all, I suggest listing if installed because this would allow me to export a list of mods I use easily if I want to share that list with someone, particularly for diagnosing an issue.)
I also suggest that you include a method for authors to write their own meta-data. No more allowing non-authors to submit data to CKAN too. Authors must be the ones to submit their information to CKAN, and a file that comes with mods can correct any meta-data CKAN has on the mod. That's for another topic though I suppose as this one is specifically about opting in and out and the results of you not enabling it.
The text was updated successfully, but these errors were encountered: