Proposal with changes to the organization Manifest. #53
Conversation
|
TIL we have such a thing |
| @@ -35,28 +35,37 @@ not present any other legal issues. | |||
| * OSI approved license are strongly preferred. | |||
| * Mods do not need to be minetest-licensing compatible (meaning, (A)GPL3.0+ is fine). | |||
| * Non-OSI licenses may be acceptable, but this is determined on a one-by-one case. | |||
| * Pure Public Domain is not acceptable, however WTFPL, MIT or similar usually is acceptable. | |||
| * Pure Public Domain is not acceptable, however ISC, MIT or similar usually is acceptable. | |||
There was a problem hiding this comment.
what about CC0, does that count as "pure public domain"?
There was a problem hiding this comment.
No, I consider it not the same. For now, CC0 is, in my opinion, OK for the time being.
|
|
||
| Modpacks (groups of mods bundled together) are not permitted in minetest-mods, as they | ||
| make management more difficult and prevent users from installing only parts of of a | ||
| modpack. For cooperative maintenance of modpacks, see the minetest-modpacks team instead, | ||
| or look at the minetest-games project. (At the time of writing of this document, those | ||
| two teams/projects do not exist). | ||
| two teams/projects do not exist). A few modpacks exist in minetest-mods, but they are | ||
| the only ones and new modpacks will not be allowed. |
There was a problem hiding this comment.
while those are technically modpacks, they are so for organisational reasons (mesecons comes to mind)
they aren't modpacks in the traditional sense: collections of unrelated mods to provide a complete experience for users
maybe clarify that or something
There was a problem hiding this comment.
I prefer not to, because providing a technical exception case as to why modpacks are allowed will not be helpful in the long term I think, as people tend to look for excuses.
Having a historical cut-off (no more from now on) is a good way of saying "these mods were used on dozens of servers for years and we don't want them to become stale" while still being able to say "new modpacks should preferably be split up or made into a single mod" to new mods and bring the argument that those new mods aren't widely used yet so it's a better time..
All of this is also "at our discretion" as well. We can still make exceptions.
There was a problem hiding this comment.
I don't really like to idea of outright dismissing modpacks. We can reject modpacks that have a bunch of unrelated stuff, but splitting mods up into modpacks can be useful for organization (eg, Technic and Mesecons and previously mentioned).
It seems like this would only encourage modders to combine a modpack into one huge mod, which isn't really any better.
|
@Ekdohibs @rubenwardy @ShadowNinja please review |
|
|
||
| The project admins reserve the right to discontinue, remove or refuse any project based | ||
| on legality, content or other, at their discretion. | ||
| on legality, content or other, at their discretion. However, removal requests for other | ||
| than reasons other than non-acceptable content or licensing are unlikely to be granted. |
There was a problem hiding this comment.
Duplicate other than.
Also, a different wording that I think works a bit better:
The project admins reserve the right to discontinue, remove or refuse any project based
on content, licensing, or other reasons, at their discretion. However, removal requests
for reasons other than unacceptable content or licensing are unlikely to be granted.
| is found to be insufficient by either the admins or the authors, then the organization | ||
| including admins, authors and committers shall appoint the appropriate amount of | ||
| new admins to the organization, and the existing admins shall grant the adminstrator | ||
| access to the new admin on the organization's github organization. |
There was a problem hiding this comment.
I don't like the emphasis on "number". You can't just count people to determine how capable they are of handling a workload. I think this should focus more on whether the current administrators are able to handle the workload.
|
|
||
| Modpacks (groups of mods bundled together) are not permitted in minetest-mods, as they | ||
| make management more difficult and prevent users from installing only parts of of a | ||
| modpack. For cooperative maintenance of modpacks, see the minetest-modpacks team instead, | ||
| or look at the minetest-games project. (At the time of writing of this document, those | ||
| two teams/projects do not exist). | ||
| two teams/projects do not exist). A few modpacks exist in minetest-mods, but they are | ||
| the only ones and new modpacks will not be allowed. |
There was a problem hiding this comment.
I don't really like to idea of outright dismissing modpacks. We can reject modpacks that have a bunch of unrelated stuff, but splitting mods up into modpacks can be useful for organization (eg, Technic and Mesecons and previously mentioned).
It seems like this would only encourage modders to combine a modpack into one huge mod, which isn't really any better.
|
@rubenwardy if you have time, please. |
|
I need to revise the text and incorporate some of the comments. I'll make a new version. |
| and mod metadata is present. description.txt is required to be present, and we strongly | ||
| urge mods to have mod.conf present, as well as a screenshot.png file, a LICENSE file | ||
| and a README.md file as well. | ||
| and mod metadata is present. description.txt and mod.conf files are required to be |
There was a problem hiding this comment.
Joining the partly late. While going towards 5.0.0, description.txt is no longer required since it can be included in mod.conf.
There was a problem hiding this comment.
Thanks, we might want to keep it until 0.4.16/17 servers are mostly gone, though....
|
This is still on my rader to rewrite and revise. |
Please review this PR and acknowledge your support or opposal. We'll first review this change with admins, and then later authors and committers.