This is the roadmap of the remaining features I intend to implement in the server over the next time.

Documentation

• Needs proper Javadoc HTML formatting.

Fully automate Transifex integration

The syntax to update all details of a resource is

curl \
	-g \
	--request PATCH \
	-H \
	"Content-Type: application/vnd.api+json" \
	-H \
	"Authorization: Bearer TOKEN" \
	"https://rest.api.transifex.com/resources/o:widelands:p:widelands-addons:r:RESOURCE" \
	-d \
	'{"data":{"id":"o:widelands:p:widelands-addons:r:RESOURCE","type":"resources","attributes":{"name":"NEW_NAME","priority":"PRIORITY","categories":["CATEGORY"]}}}'

Placeholders therein: TOKEN, RESOURCE (2×), NEW_NAME, PRIORITY, CATEGORY (list)
Valid priority is "normal" "high" "urgent".

To delete an existing resource, use --request DELETE and omit -d ... and the content-type header.

• This will be added as an extension of the CMD_SETUP_TX command and all parameters can be set via the Widelands admin UI.
  Then every server maintainer can setup new add-ons, and not just Transifex maintainers.

@mentions in comments

• How will anyone notice you dropped them a comment? They probably won't. If you just want to state an observation, comments are fine, but for the purpose of conversation about an add-on their usefulness is quite limited. E-Mail notifications when you @mention someone in a comment on an add-on, as well as for all new comments about your add-ons, shouldn't be hard to implement. Unless anyone has an objection to this feature?
• [ ] An option to subscribe/unsubscribe to receiving notifications about all new comments on a specific add-on, like for forum threads, might also be nice but probably overkill – opinions?
• This reminds me that limiting everyone except admins to edit their comments only within 24 hours after posting (like on the forum) is also an easy-to-implement anti-spam measure.

Re widelands/widelands-website#359

Whitelist / Blacklist

• When a trusted member of the development team uploads an add-on there is probably no need to mark it unverified automatically every time. And the twice-daily Europeans updates are also not a likely source of spam ;) I want to allow adding some rules like "when user A uploads add-on (B | any) then set security status to C (and | or) quality to D" to override the defaults.

• There has been no spamming the add-ons server yet (though a few instances of what might have been failed hacking attempts) but the possibility to block individual users from uploading content and/or commenting on (specific or all) add-ons should better be implemented early so we have it ready if we ever need it.

• I'm not sure whether users who deleted their account and users whose website account has been deactivated due to spamming can still connect to the server if they set a gaming password in time; but the server does not perform any checks for this yet. I also don't know whether a deleted user's old username will still be shown. I assume there are related flags somewhere in the database – @frankystone do you know which columns in which tables are relevant for this?

Versioning

• Increasing the protocol version for every minor feature will quickly become unmaintainable. The next protocol version increase should feature the addition of a command version for each command. If each command is prefixed with its own version number, changes to one command's syntax won't touch the rest of the codebase.