From ba9d623d6c833b82891319d3b28c5915e2bffe8c Mon Sep 17 00:00:00 2001 From: Robert Zenz Date: Thu, 25 Feb 2016 22:29:47 +0100 Subject: [PATCH] Added first draft of the features guide. This time for real. --- 2-guide-features.markdown | 84 +++++++++++++++++++++++++++++++++++++++ 3-manual-issues.markdown | 4 -- 2 files changed, 84 insertions(+), 4 deletions(-) create mode 100644 2-guide-features.markdown delete mode 100644 3-manual-issues.markdown diff --git a/2-guide-features.markdown b/2-guide-features.markdown new file mode 100644 index 0000000..f2a1194 --- /dev/null +++ b/2-guide-features.markdown @@ -0,0 +1,84 @@ +A guide to gauging features +=========================== + + +0. Purpose of this document +--------------------------- + +The purpose of this document is to provide a guide on how to gauge features +whether they belong in Minetest or not. Though, by the very definition of +the subject, it is impossible to provide a comprehensive and exact manual, +instead this document tries to outline a common approach on how to evaluate +features and provide a good foundation for further discussion if necessary. + + +1. Consider the mission statement +--------------------------------- + +There is a very simple question which can be asked for every feature: + + > Does it help with achieving the goal of Minetest? + +And if in doubt asking the opposite question might help: + + > Does it hinder achieving the goal of Minetest? + +If the second answer can be answered with "no" there is a good chance that +having the suggested feature is a good idea. Additionally there is a question +which should also weigh heavy: + + > Does somebody want the feature? + +If somebody wants a feature and maybe even writes it themselves, there is a good +chance that this feature is also desired by others and will ultimately help +with achieving the goal. + + +2. Flexibility +-------------- + +For Minetest to be flexible it requires features and these features must +be flexible. So an additional question that can be asked is: + + > Can it be configured? + +Though, this question doesn't necessarily make sense for every feature to be +asked, but raising the question might actually show that it might benefit from +being configurable by either the modder or user. + +Additionally one can ask themselves: + + > What else might this feature be used for? + +For example, the tree spawner is not limited to trees, even though it might +be designed to spawn trees it can easily be used to spawn completely different +structures. + + +3. One-size fits all +-------------------- + +There is no difference between features for modders, users or both. All features +can be judged by the simple questions above. For example shaders, they do not +directly help with achieving the mission statement, but do also not hinder it, +they can be configured by the user and many people want it. So the choice if +the feature is used (and how) is actually not upon the developer, but upon +the user. + + +4. Having a lot of features is not bad +-------------------------------------- + +This is a contentious point, but everyone will agree that a software which does +not offer features will not be used. On the other hand, offering many features +can quickly lead to the opinion that the software is bloated, complicated or +both. So it is important that features actually stay out of the way until they +are wanted or required. Providing many features is not a bad thing, providing +many features which are somehow required or interleave with each other is a bad +thing. + +Having a feature rich engine means that it offers all the features which might +be required, and also has the cleanliness that all these not needed features +stay out of the way until they are required. The developer should not even need +to know that these features exist if they don't use it. + diff --git a/3-manual-issues.markdown b/3-manual-issues.markdown deleted file mode 100644 index dd4d538..0000000 --- a/3-manual-issues.markdown +++ /dev/null @@ -1,4 +0,0 @@ -How to handle issues -#################### - -