Guidelines for moving gameplay features into mods.

[Treah]

Hey all I thought i would open this issue so that it can be discussed on what exactly is the requirements to move core gameplay elements into a mod.

This is in reference to a few changes that have happened in the past. One of these is the crazy cataclysm mod in #16180. This is not intended to discuss specific items or monsters at all but since that issue is used in recent changes to justify moving items out I thought it might be useful that guidelines for moving anything out of the game into a mod needs to be laid out in order to prevent community backlash to such changes. This will also hopefully prevent useless discussions on individual changes that are being proposed.

So let's start with what Kevin put down as requirements for something to be added to the black list.

1. They need to be Jokes
2. They do not exist in reality.

Since this was blacklist requirements and not moving items into a mod they are bit lacking and I do think that a real discussion is warranted on this.

I think the main issue here is that what is core gameplay is an opinion of one person to the next so there is potentially precedent to move anything into a mod based on the opinion of such author.

I have come up with some guidelines below that hopefully is a starting point for such a discussion.

1. Moved elements must have concise and understandable relationships between each of them so that they are grouped correctly.
2. Mod titles need to be easy to understand what type of elements are being added and not require a user to go to the forums to read about to understand what it does ( possible rewrite on descriptions ingame dunno )
3. Mod needs to have an active maintainer, elements should not be removed into a mod that then will be ignored or not supported by the main dev team. Elements should not be moved into a mod in hopes of getting someone to do the work as that's wishful thinking.
4. An existing mod should be considered before a new one is created. This is to prevent mods with simply a few items as it adds little value and causes clutter.
5. When considering making a new mod, elements for the existing game should not be removed then peppered into the mod just to give it a few "starting" items in hopes that others will add more. This is again wishful thinking.
6. There needs to be a technical reason to move the elements out into a mod not simply because its felt they are not core elements or that it's the opinion they don't fit in.

I for one think 6 needs more clarification but I am at a loss to describe it better as it would have prevented Kevins change and I for one agree with that. Maybe if many users agree on it then it can override that requirement.

Let me know what you guys think and if you can please add a discussion flag to this it would be helpful.

[mugling]

If you want to discuss things in broad terms with a wider audience then the forums would be more appropriate. The odds of reaching consensus is very low here. Issues are best discussed on a case-by-case basis once an implementation exists (or someone intends to work on one).

[mugling]

Perhaps a more philosophical answer is in order (no snark is intended).

Github is intended for:

• reporting an issue
• pushing some code
• reviewing some else's code
• proposing a feature

Whilst there is a lot of scope in the latter it doesn't include writing design documentation via committee. In an open source project such approaches are always doomed to failure.

Firstly, only ideas with an implementation have any realistic chance of gaining traction. Design documents don't provide an implementation and it's almost impossible to write a good specification if your not entirely sure what the problem is your trying to solve. To your credit you do recognize that uncertainty in your sixth point.

Secondly, open source developers write the code that interests them for the ideas that they support. If you think about it why would they do otherwise? This links in with my first point that without someone to implement it a specification is unfortunately of little use. As an added problem such efforts usually detract from actually working on the project itself.

Thirdly, and perhaps most importantly, open source isn't, and shouldn't be, a democracy. That might sound wrong to you at first but consider that we held a vote today; do developers who join in two years time still have to agree to the result even if they had no original say? When people say democracy in open source what they actually mean is land rush, and that is wrong. Notwithstanding the practical issues of conducting a fair vote in the first place.

You're best thinking of open source as a meritocracy because that is de facto how such projects function. Those with either a good idea or the ability to implement one have the greatest chance of influencing the project. We'd get nowhere if it was the reverse.

There are lots of other ways you can influence the outcome. Bug reports and features requests are always welcome. Feedback from the user base is also very important but again the influence is not from the force of numbers but from the merit of the suggestion.

Sometimes specifications are unavoidable. A good example is our astyle coding standard which I personally dislike but is definitely preferable to having no standard. This isn't one of those cases though.

Hope this makes the rationale for some decisions a little clearer

[Coolthulhu]

http://smf.cataclysmdda.com/index.php?topic=13267.0