The Lord of the Rings Minecraft Mod Wiki
The Lord of the Rings Minecraft Mod Wiki

LOTR Mod Feature Improvement Proposal Process[]

This is a proposal for a system (tools, procedures and organisation) for an improved method to collect and present proposals to improve the LOTR Mod = the 'Process' or 'FIPP'. It was written in a period of intensified discussion about the system as-is in early 2016. Main motives to prepare this proposal are presented here.

The status of this proposal is 'Second Draft'. The first draft was issued for comments to Sinthorion on 20160205. Since, insights based on feedback in this thread have been added to the proposal.


The objectives of the FIPP should first of all be to serve Mevans and his team, and the community that uses the LOTR Mod. More specifically: For Mevans:

Identify improvement options of existing features and identify additional features to improve the mod. These must prove valuable for the intended gameplay the mod offers to the community, have acceptable difficulty to code and are fun and meaningful to work on.

For the community:

Provide a platform where Wikia Contributors can post their improvement ideas, for both existing and additional features.


The deliverables are the 'tangible' (visible) results of the process to achieve the objectives mentioned above. Together with the objectives these deliverables determine the starting points for definition of tools, procedures and organization required for the process.

For Mevans and the community:

A clear overview of traceable improvement proposals, along with the planned features, categorized, presented in an orderly manner and updated on a regular basis by a small team that can be held accountable for the overview.

For the community:

A clear and straightforward procedure and platform to post improvement proposals and have them reviewed by other contributors and responsible and accountable review teams.

Starting points / Prerequisites[]

  • No 'okayed' proposal info shall be lost from view and be accessible through some structured portal.
  • All proposals shall be processed by a moderator and a review team.
  • Procedures must be clear and communicated properly.
  • The general required quality level of new proposal entries should minimize waste of efforts of both Contributors and staff / review teams.
  • Make sure to not scare off users that come up with simple improvement proposals, with an overly complex procedure, but help them post a meaningful entry and easily find info on related posts and features.


This section describes the proposal for the FIPP.

General aspects[]

Stop using the term ‘Suggestion’. Instead use the term ‘Proposal’. That has a stronger connotation and stresses that contributors are supposed to actually come up with proposals that are well thought-through and backed by some (limited) research through the available lists.

Keep the suggestions forum for ‘New feature proposals’. Use the feedback forum for ‘Existing feature improvement proposals’. As an alternative all can be collected in one forum while categorization is used to distinguish 'new' from 'improvement on existing'.

Both ‘New feature proposals’ and ‘Existing feature improvement proposals’ are ‘Improvement proposals’.

Modify the titles of both feedback and suggestion forums accordingly. Modify the explanation and instructions on both forum pages to ensure contributors are fully aware of what is expected from them, how to enter a decent suggestion, what will be done with the suggestions, etcetera.

Proposal templates[]

Use templates for proposals, as a recommended aide for posters. Contributors should follow clear instructions to use these. The templates, with clear headers for sections, should be usable in the visual mode of the Classic editor by copy-pasting from a source. Automagical preparation is preferable so contributors only have to fill in the blanks. A brief description per section with simple but clarifying examples should be included in the instructions. An indicative list of headers and accompanying questions to be answered with each header:

  1. Title: The title of the proposal must identify the feature covered and be specific.
  2. Feature: Does it concern an existing feature? If so, which? Describe the feature addressed and the feature category/-ies it belongs to.
  3. Motive & Objective: Which problem/inconvenience is solved with this improvement? How does the proposed improvement add to the mod users amusement?
  4. Assumptions: Which assumptions are relevant to the proposal? Mention them if any. This may for instance limit the alternatives to achieve the same objective.
  5. Related proposals: List any related proposals found in the proposal category pages (see below).
  6. Proposal: Describe the proposal.

General guidelines are valid, as they are now: be specific, concrete, original, etcetera. Proposal entries (a new thread) can cover multiple, related, sub-proposals. It may be wise to use multiple posts in one thread, as these can all be separately kudoed.

Improvement proposal management[]

Prepare and present a list of feature categories that will be used as reference to categorize any proposal and to order lists. There will be Improvement proposal category pages for each category named ‘featurecategoryname:Improvement_Options’. Note that the meaning of the term 'category' as used here, is not the same as used for 'category' in the wikia domain. As an alternative we could create feature (category) pages, which will simply include the overview of improvement proposals.

Proposed categories: ‘Gameplay’, ‘Factions & NPCs’, ‘Mobs & Animals’, ‘Structures’, ‘Blocks & Items’ and ‘Biomes & Vegetation’. Each will have a number of sub-categories that will be the sections on each of the improvement option category pages.

  • Example1: ‘Structures’ may be ‘Major’, ‘Faction’, ‘Composed’, ‘Special’ or ‘Ambient’.
  • Example2: ‘Gameplay’ may be ‘RPG & Combat’, ‘Quests’, ‘Transport’, ‘NPC interactions’, ‘Graphics & Sounds’ or ‘Others’.

Each sub-category will have a list of planned features and links to approved improvement proposals with brief summaries of the main aspects/features and of the thoughts behind the proposal. It’s up to the review teams to determine how to arrange their category pages.

The Planned Features list and page will remain as-is, as this represents Mevans’ commitment to future updates. He will and cannot be held accountable for any other Improvement options.

Each Improvement option category page will be managed and maintained by an Improvement option category Review team, consisting of 1 admin, 1 or 2 moderators and 2 non-staff contributors who have shown to have expertise and judgemental capabilities. These teams will judge, by consent (= agreement by absence of unsurmountable objections), whether ‘Locked’ proposal thread contain proposals are worthy of getting the ‘Okay’ status or whether they will be ‘Discarded’. They will update their Improvement option category page accordingly, with updated info on ‘Okay’ proposals. Ideally this will be done with the same or higher frequency than that of the launch of mod updates.

Evaluation procedure[]

Only allow registered contributors to post new proposals. If possible, allow non-registered contributors to respond to proposals. If not, don’t allow it. The entry threshold must be raised. Define 5 statuses for a proposal: ‘New’, ‘Evaluating’, ‘Locked’, ‘Discarded’ and ‘Okay’. As alternative to 'Okay', 'Accepted' may also be considered.

Use these as status indicators in the title of proposal threads.

  • Example1: ‘New: Atlatl spear throwers for Lossoth and Cerinrim’
  • Example2: ‘Okay: Boomerangs for Limwaith’.

The procedure following the posting of a new thread would be:

  1. After a new proposal thread is posted, the status is ‘New’ and other contributors are not allowed to respond yet. Newly posted threads should preferably be auto-locked upon posting.
  2. A moderator should check the post on meaningfulness (judgement based on FAQ and no-to-suggest-list, rules and use of template (not too strict!) no judgement on the actual proposal content itself!) and when approved, change the status to ‘Evaluating’. If not okay, the proposal thread owner (the original poster) has a week to improve his/her proposal. If after a week the proposal is not approved for evaluation, the proposal thread status will be changed to ‘Discarded’, locked and removed from public view.
  3. During the ‘Evaluating’ stage, proposal thread owners are supposed to update their original post based on the feedback they’re getting and consequently improve their proposal.
  4. After min. 1 to max. 2 months moderators may decide to change the status to ‘Locked’ or decide to keep the thread open for a while, as long as there is reason to believe an owner may still improve his proposal. A brief message announcing a lock may trigger an owner to conclude.
  5. After locking the title will show the ‘Locked’ status. Locked threads will be reviewed by improvement proposal category review teams. These teams will decide on changing the status of a proposal thread to ‘Discarded’ or ‘Okay’. The number of 'kudos' a proposal has received from the community must be considered an important, yet not the only determinant, factor in their judgement. After that decision, the title will be changed accordingly and the thread will be moved to either the ‘Discarded improvement proposals archive’ or the ‘Approved improvement proposals archive’. These are not to be used as forums, but only maintained for contributors and Mevans to view, and for the review teams to refer to on their pages.

Eru interventions[]

Mevans himself is free to overrule any decision by the review teams. On a regular basis he may decide to discard a number of ‘Okay’ proposals and inform the review teams on his decision. This shall be followed through by the review teams accordingly.

User liberties[]

Apart from this, Users are allowed to present their improvement proposals in any form under their own user domains, including improvement proposals of others they wish to support.