Area administration

[Mask]

Hi there,

This forum should now be visible to everyone?

With Dalvyn's departure, the question now is how do we administer areas going forward. The kind of administration required is someone to review new areas before they are added to the game, fixing bugs in areas, helping builders with area related problems etc.

The 'fkbuilders' email has been discontinued, and the above work should probably now take place in this forum, with the exception of the 'area review' process as it would reveal too much 'behind the scenes' info if it was all put in the public domain.

We will need to decide on a process that works - how many people should review and sign-off on an area file before we can include it, and who those people should be.

Also, we need to re-work the way we currently handle 'area' files - as it's almost certain that we need to have some kind of version control so that changes made online are correctly persisted through updates. Ie, if someone writes an area, it's put on the main port and some RP causes some of that area to change, then the author wants to add another quest or extend the area in some way, we need to ensure that the in-game changes are correctly persisted. This might mean that builders would need to use something like TortoiseSVN - unless anyone has a better suggestion?

Cheers,

Martin

[Lathlain]

Use of Tortoise sounds grand to me, given what you've said. I assume it's possible to allocate certain areas to specific people this way - but my knowledge of the system and its alternatives isn't really sufficient to explore this further right now.

The area system as a whole has always felt pretty well refined to me. At present it seems to go a little something like this:

1.) The builder requests permission to build an area.
This was done through the builders email, but could just as easily be done through the applications process - or a builder process set up in the same way.

2.) After a dialogue, confirming details etc, the builder is assigned VNUMs and told to go forth.
Provided we can establish a list of current VNUMs and their usage patterns, it shouldn't be difficult for a member of staff to find and allocate the suitable VNUMs for the job.

3.) The builder, depending on experience/preference will either build offline or in OLC if they have the means to.
We currently require builders to build at least one area offline before allowing them access to OLC commands. I see no reason to change that, though I'm open to feedback.

4.) The area is submitted for initial review.
We presently have two area reviewers, though it never hurts to have more hands for the job. Different people can specialise in reviewing grammar, standardisation and prog testing for instance - it would be a good way to involve people who want to help out, though these people should probably be established builders or staff due to the sensitive information that would be available to them.

5.) The area is adjusted and sent in for further reviews until deemed complete.
This is all down to the review process and how easily everything can be rectified. We would need a forum post for all of the building standards and principles made easily accessible to builders and reviewers, so we're all on the same page. The existing builders forum is also used to request help and advice when needed.

6.) The area is brought into game.
It has always been a policy that areas are to be submitted as complete modules, and not left intentionally half finished with an eye to completing them later. Spelling mistakes and program issues can be fixed easily after the final submission, however.

I don't see any glaring need to radically overhaul any of the above process, but there's always room for improvement of course! What do people have in mind?

[Harroghty]

I looked up Tortoise today. I am not sure that I totally understand it. (I do like that it has a German language option!)

The problem that I see with the system right now is that it demands a lot of time and focus of the two building administrators (Ed and Todd) to review an area. I get tired reading my own area and I know it more intimately, but I can only imagine trying to decipher it all as a third party. I do not really see any way around this except minting more junior admins to do initial reviews and save them time. They can then complete a final review after minor corrections have been completed by the builder at the direction of the junior admin. The junior admin (Journeymen) would submit notes to the admin that reflect their changes to catch the admin up to speed.

The only recommendation that I have to streamline the current very logical system that Ed outline in his post is that changes be required in an itemized format. i.e. the file would be submitted and a document would come with it like this...

Changes

Original program on mXX05:
>speech_prog yes nahm si ja oui~
mpechoat $n {70}$I nods very sagely.
say It used to say this when you triggered the prog.
~

New program on mXX05:
>speech_prog yes nahm si ja oui~
mpechoat $n {70}$I nods very sagely.
say ...but now it says this.
~

As a measure to encourage accuracy and circumvent cleverly forgetting changes, the admin could pull the .ARE file from the gameport and change only the itemized changes. This would ensure that the right file was getting changed and it would prevent any subterfuge on the part of the builder (like slipping in another change somewhere in the file).

[Mask]

The advantage of a change control system such as http://subversion.apache.org is that it provides this level of control automagically. Ie, if a builder makes a change to an area file and the 'commits' it to the repository, all reviewers could get an email containing the list of changes made to that file, ie, along the lines of:

Code: Select all

Author: ed                                                                  
Date: 2010-03-22 20:32:32 +0000 (Mon, 22 Mar 2010)                              
New Revision: 206                                                               
                                                                                
Modified:                                                                       
   area/tantras.are                                   
Log:                                                                            
This door should be open

@@ -2978,7 +2981,7 @@
 DDIR_EAST
 ~
 gate gates~
-EX_ISDOOR|EX_CLOSED -1 5500 1
+EX_ISDOOR -1 5500 1
 DDIR_WEST
 ~
 ~

We don't want a situation where reviewers have to manually apply changes to a file - time-consuming and error-prone!

That would give us a process like:

1) Builder makes changes locally to their area file.
2) Builder attempts to commit the area file to the repository. If their copy is out of date due to changes made by others, they will need to update to the latest copy first.
3) Builder commits the area file, an email goes to the reviewers with info on the change as above.
4) Builder logs into test port and issues a command similar to the existing 'download' command that instructs the test port to update it's local copy of the area to the latest version.
5) Builder reboots test port to get latest copy into the game.
6) If Builder is happy, builder asks in forums for the area to be reviewed. Reviewers can choose to review the whole file or if they've already reviewed a previous version, review just the changes made since the last review.

Complications:

1) What if a 'collision' occurs. For example, the game has version 100 of a given area. A reviewer is working on this revision and made some changes to it using OLC, and then goes to 'save it' (by issuing a 'foldarea' command which would also need to commit the new version to the repository). In the mean time, the builder has committed version 101. The game tries to save and commit the version they changed with OLC and then commit it, when subversion detects that the version being used by the game is 'stale', and requires that the game update it's version first. If the two sets of changes are in the same area, subversion will not be able to merge the changes, resulting in a merge conflict. How would this get resolved? The only real option I can see is that OLC changes are blocked from being saved if the game didn't start up with the latest copy of the area file, which could be annoying.

[Mask]

Anyone out there want to put their hand up for reviewing areas? Note that it's probably essential that you would already have built an area offline as otherwise you will go mad looking at tildes!

[Caelnai]

I'd like to help out reviewing. It's something I've done quite a bit of over the years, as I'm an offline builder.

[Liandria]

Pardon, I can't really offer much input on this as I'm not an experienced builder, or capable of area reviewing. Could you maybe clarify who Ed and Todd are? I don't know many of the staff/builders by their firstnames.

[Enig]

I know how you feel! I'm pretty terrible with names too.

In this case, Ed is Lathlain and Todd is Kregor.

[Harroghty]

I'd like to review areas also, but I will maybe need to wait until I get back to the U.S. (on or around 6 May now) to start. I don't have the time to learn a subversion program while I'm here, but I do like that idea now that you've explained it. It is a lot like MS Office's "Track Changes" feature; that feature is great and this sounds good also.

[Kregor]

I think, ideally, we should have three sets of eyes. An area should go through at least two sets of eyes by the time its made final review. And the builder's eyes don't count - going on my years of copy editing background, that's the rule. So if one of the builder admins is hands-on building the area (and with both Lathlain and myself in active construction on multiple areas, that's going to be the case often), that takes one admin's eyes out of the mix. So we need at least three sets to make sure we get a good review process.

As far as a version controlling mechanism, I'm afraid that's one way that I'm a bit old fashioned. Mark up a copy, hand it back, get a new edited version handed back, pass it on to the next reviewer to do the same. If it diverges too much from that simple copy flow, it's gonna cramp my style

[Duranamir]

I would support usage of Subversion, it is something i have used at work and for small teams (what i am used too ) it works really well.

And as far as reviewing areas thas is also something i would happily do, i have a fair degree of building experience as well as being an IT professionl in real life.

Duranamir.... otherwise know as Adrian

[Lirith]

I doubt I'd be much good at checking code, but if anyone needs proof-reading for mobs/rooms or quest run-throughs checked for errors and typos, feel free to give me a nudge.

[Lysha]

I was thinking the same.

[Duranamir]

Has any descion been made about process, as i do have a new area i would like to build. Previously i have always sent a rough design to the builders e-mail/Dalvyn for checking before i even start building, to who or into what forum should i now send this design ?

Duranamir

[Lathlain]

The current process, which I really should officialise somewhere, is to send all applications to build an area directly to the applications forum. They'll each be handled on case by case basis - and when it comes to submitting an area for review, just PM one of us and we'll set you up with somewhere to email it temporarily.

[Mouat]

Martin, Todd and Ed.

I'll throw my hat in for reviewing. I've never really coding an area before, although my knowledge of imm command is fairly decent. I am good with logical sequencing. I can edit and create web pages from html (I know not the same thing as area coding...) and I have had lots of experience with mprog commands to view code when helping people troubleshoot on another mud that I have been an admin for a few years...

Oreste (Mouat/Rynn).