[Feature] Requests - Crowd sourcing the world

Bugs & Features
#1

We currently have a simple request feature allowing interaction between room/area owners, but I have this idea of an improved request feature…

The basics

A request is a set of one or more changes (edits to a room description, creation of a new exit, a new area image, etc.) that anyone can make.

Example

John wants to add his home area, John’s Den, to the Forest. He creates a request with 4 changes:

  1. create an exit from Outside John’s Den to Forest Path
  2. create a return exit from Forest Path to Outside John’s Den
  3. set The Forest as parent area to John’s Den
  4. edit the Forest Path description to include a note on this new trail

The request is sent to all the owners affected by any of the changes.

Example

Since Raeth owns the room Forest Path, and Accipiter owns the area The Forest, both Raeth and Accipiter gets the request.

For request changes to be applied, all affected owners must approve it. Any affected owner may add/remove changes to the request.

Example

Accipiter approves the request. Raeth, however, notices a spelling error in the new Forest Path description. He corrects it before approving.

Since the request is modified, both Accipiter and John needs to reapprove the edited request. Once done, the changes are applied.

Requests will show up in the Player panel (under the Bell-icon), and may be approved/declined. This can be done without waking up the owning character.

Public voting

An extended idea is to also allow public voting.

Once a request is made, the affected owner(s) may choose to let the public decide whether to accept or decline. When another player’s character enters an area, an indicator will show if there are any requests made public that they may vote upon.

Opening a public request, they can view it and vote to approve or disapprove. The request is open for voting for a set duration of time. Once the duration has passed, the request changes will be applied if a high enough percentage of players approved.

Area request mode

An area owner may configure a request mode which is applied to any request that affects the area, its rooms, or room exits. It will have 3 settings:

  • Manual (Default) - The owner(s) decide to accept/decline/make public
  • No requests - Requests are automatically rejected
  • Public - Requests are automatically made public

Moderation

Some measures may need to be taken to avoid abuse of public voting:

  • One vote per player (obviously)
  • Builders/admins may instantly Accept/Decline public requests
  • New players may need to unlock Voting based on some criteria

Challenges

I started implementing this, but ran into some question marks:

  • Request creation GUI - I couldn’t come up with a simple GUI/workflow to create and manage requests. But since creating requests may be considered an advanced feature, maybe it doesn’t need to be that simple? Maybe I can rely mainly on commands?

  • Voting GUI - The GUI for public voting would differ somewhat from normal request handling. It should probably be under the Area panel, and not Player panel? I need to think this through.

Well… that is what the idea looks like now. Feedback is appreciated as always! :smiley:

/Accipiter

1 Like
#2

Public Voting should probably not be a thing as far as any sort of mechanical backend is concerned. An unofficial advisory vote seems like a solid plan, but somebody should be hands on with final approval.

1 Like
#3

Thanks for the input! :smiley: My thought was that the Manual setting for the Area Request Mode would cover that. The owner would then have full control of what the public may vote on. But instead of a “final approval”, it becomes a “pre-approval”.

Voting criteria

One might however also want to give the owner the possibility to customize the criteria for the public vote to pass, using options such as:

  • Voting duration
  • Minimum number of voters required
  • Percentage of approval threshold

Change history

Another possible extension is to also add Change history, allowing for owners to rollback previous changes. May be needed to counter vote-highjacking where a player uses multiple accounts to pass their own request.

. . .

All in all, this whole idea would allow admins/users to create realms/areas that are static (No requests), that are completely wiki-style crowd sourced (Public), or something in-between (Manual).

#4

This sounds pretty cool! That said, I think it would make sense for an area owner to allow a room owner to handle things. So perhaps a toggle for “allow owner to approve changes” would help with that. That way, management of large areas will able to be delegated to individual owners.

#5

I am not entirely sure that I understand.

The example above is a bit weird though, and your comment might be because of that. Unlike the example, the area owner should usually be the same as the owner of the area’s rooms.

And, yes @Raeth, you should be the owner of the area The Forest! :smile: I will make it so (tomorrow. Now I need sleep :zzz: ). You should have control of both the room where their exits would lead, and of the area which they will be part of.

But in other cases, I think it is valid to say that all owners affected by a request need to approve it before it is applied.

Proxy group

I have also been vaguely thinking about a feature where you can create named groups of characters. And then you could assign a group to areas and rooms, to act as proxy, so that anyone in that group may respond to these types of change requests instead of just the owner.

This way, you can have multiple people being in charge of a public area.

I also imagine using these type of groups for things like in-game mailing-lists, area access (maybe you must be part of a specific group to be allowed to use an exit), and stuff like that.

But that is for later :sweat_smile:

#6

Ah okay. Well, when they’re the same that makes much more sense. :stuck_out_tongue: If it would be rare that they’d vary, then there’s no issue. I was just concerned that if someone owned/managed a large area which was subleased to other users, they may have denizens who requested connections and edits frequently enough that it would become cumbersome on the zone owner.