TMW Admin Role and Responsibilities

[Kazenawa]

The following is not directly related to this topic. Feel free to move it if needed.

It is possible that the problem affecting forum emails is related to this, but I kind of doubt it.

I would appreciate feedback from:

• one person who is not currently a member of the tester group, nor any group with special permissions (i.e. most forum members)
• one person who is a member (but not a leader) of the tester group, but not any group with special permissions (i.e. a tester who is not a developer)

regarding whether they can see

• who are the leaders of the testing group
• whether anyone is in the request queue for the testing group

I fit with the second case, as I am a member of the tester group, but not a developer.

I can see that Jenalya, tux9th and wushin are the leaders of the testing group. I can also see the whole list of people belonging to this group, classed by their joining date (37 persons). However, I am not able to see any request queue currently, and I haven't been notified of any new entry since I've joined it.

Concerning notifications, I receive a mail on this website when there is something new to test, but I don't receive anything on my gmail mailbox (it's also true for forum topics I have subscribed).

Just another piece of information, although I am not sure if it can help : I still receive e-mails (on gmail) when there is a new answer to forum topics I am subscribed on tmw.net. On these forums I have the same behaviour we had before.

Regards,

Kaze

[o11c]

What a blatant lies.

Nope, these are not lies. IIRC, Doorsman left project after asking how to challenge your decisions. Then you've told your decisions can't be challenged. That's exactly how tyrant looks like. Furthermore, fact of appearance messages like this indicates quite many people considered you tyrant, up to degree you can't just stay silent about situation.

/me prefers MasterKenobi's resignation, but all the good stuff is in the private forum.

Fixing those crashes and related things was the primary purpose of the big code update.

Map server still crashes sometimes (probably also losing some logs in process ). Maybe even more than before (it's possible to introduce new bugs when fixing old ones, etc). I counted about 4-5 map server crashes after update and I do not remember so much crashes before. Though without crash dumps I can't tell what code crashed, sure. Also, 4144 told there are still easy ways to crash server. That's "player visible" part. I think you should be more careful about statements when grilling someone for bad job.

I am disappointed in the number of crashes that remained after the update.

However, the update *was* successful in making the crashes *reliable*, so that I could actually fix the crashes in the later patches. Few, if any, of the crashes that happened after the update were actually *new*, they were merely exposed (technical details: such as reading from a NULL pointer instead of an uninitialized pointer - the former is better even though it always crashes)

Oh, and ... as one of the people who had to restart the server when it went down, I can honestly say it *did* crash quite a bit before, people just didn't have something to blame it on. Now that a couple months have passed, I think the average crash rate is about the same.

I recall that after the last planned update before the big one, the server only managed to run for about an hour before it crashed.

Can someone give me an example of what a player would need to communicate with an admin for?

1) Reporting issues (like insane CPU loads, packet losses, etc).
2) Advanced manipulations with accounts where GMs lack enough rights. Say, renaming troublesome nicks, adding people to manamarket, etc.
3) Handling some misconfiguration/malfunction which does not lies in the code but rather system configuration related.
4) Advanced investigations where GMs lack access to required data.
5) Dealing with high-profile abusers or attacks which are too powerful for usual GMs to handle. Like advanced bans of offenders by IP range, blocking some exceptionally nasty or troublesome things on firewall way before it can reach any program and cause issues, etc.

I don't disagree that these are admin responsibilities. However, most of those are not communication between a player and an admin, and those that are fall under the "technical troubleshooting" exception.

I could dissect o11c's arguments point by point, but I think this is central to how my vision of the game and of admin responsibilities differ from his:

Only with the big code update could I finally call TMWA "alpha". The release quality of a piece of software is not driven by deadlines, popularity, or what you'd like it to be.

Alpha is very early in a product lifecycle. It's when you finally have enough stuff put together to begin testing. It's understood that there are serious problems in the code, which is why you don't trust it yet.
http://en.wikipedia.org/wiki/Software_r ... life_cycle
http://www.techterms.com/definition/alpha_software

I think that alpha-quality code should be tested on private servers until it's stable enough to be useable and progress to beta. Beta code would go on the public testing server until there's enough confidence that it won't destroy the live game server, and the changes are understood enough to put on the live server.

I am very much aware of the definition of alpha software, and I very much wish TMW were far enough to be called beta.

External availability of alpha software is uncommon in proprietary software. However, open source software, in particular, often have publicly available alpha versions

It is functional enough to be used, but is unpolished and often lacks many of the features that will be included in the final version of the program.

The only way to avoid running alpha software on server.themanaworld.org is by not running the game at all. Wishing it were otherwise accomplishes absolutely nothing.