Staff’s Job?
-
@faraday said in Staff’s Job?:
@Pandora said in Staff’s Job?:
The job of staff as a whole in any text-based game is to maintain the code, theme, and community standards through all of the back-end tasks that players do not have access to,
It's as decent a generalization as any, but it's still not quite accurate. [...]
It just varies a lot. There's no other way to put it.
Students and teachers may overlap in duties (passing out pencils, deciding who gets to use the swing first, monitoring attendance or participation, grading tests) but at the end of the day, there is a difference and it isn't definitive to say it varies - the teacher is the teacher and the student is the student.
Same goes for Staff vs Player in terms of responsibility, or as taken from the name of the thread 'job'. If a game goes down, who do players look to? Staff. If there is a disruptive theme breach? Staff. If a plot conclusion needs a game-wide emit? Staff.
Players can help, it is a community after all, but at the end of the day, staff's job is to keep everything running in all of the ways that players cannot.
-
@Pandora said in Staff’s Job?:
If a game goes down, who do players look to? Staff. If there is a disruptive theme breach? Staff. If a plot conclusion needs a game-wide emit? Staff.
I just disagree, sorry.
You're not going to look to build staff if there's a disruptive theme breach, but these people are still staff. On some games, any storyteller can do a game-wide emit, yet not be staff. There just is no universal constant.
In any kind of 'authority' system you basically have three components: Title, Responsibilities, Permissions.
Often people that a game calls "staff" sign up for additional responsibilities (building/storytelling/app review/whatever), and in turn get more permissions (access to the jobs system/commands to build or code or schedule events/etc.) and a title: "Build/Plot/App Staff".
But that's not universal. On some games you have players who agree to additional responsibilities, or get additional permissions, but without the title of "staff". Faction heads, coders and builders are prime examples of this. Sometimes they're considered staff, sometimes not.
-
@faraday said in Staff’s Job?:
In any kind of 'authority' system you basically have three components: Title, Responsibilities, Permissions
Four if you count "the guy that actually knows what to do."
-
@L-B-Heuschkel said in Staff’s Job?:
@Seraphim73 I think you're on to something very important here. Story telling, from the GM's perspective, where the point is not just writing the story, but making every bit player feel that their input mattered, that it affected the outcome.
It still comes back to somehow getting your players to buy-in.
It's a delicate balance. Give too little attention and the world is a sandbox which, as we've seen in countless nWoD cloned games that spawned and died a quiet neglectful death, doesn't work. Give too much attention and the world is being micromanaged, the players only stick figures unable to impact it in any meaningful way so they lose interest and move on.
Staff are an extension of what GMs are for table-top; they host the game and run the plot but the best laid story, the coolest GM screen or fancy dice won't mean a thing if the players are yawning and staring at their phones the whole time.
What GMs (and staff) want is players who contribute and share the creative burden of authoring this collaboratory fiction. If they don't then there's trouble in the horizon.
-
@Tinuviel said in Staff’s Job?:
Four if you count "the guy that actually knows what to do."
Lol, point.
Unrelated -- one way to look at the permissions/role/title angle is Ares' roles system. Instead of simple flags like WIZ/ROY/JUD, Ares lets you define custom roles, each of which is granted permissions to certain commands.
You might have a builder role that can build/desc/teleport around. You might have a wiki manager role who has permissions to manage wiki pages, or app review role who can view apps and jobs.
Which of these are roles are considered "staff" and which aren't? The game owner decides in the game configuration, but that decision doesn't actually change anything on a practical level. The only distinction between a non-staff role and a staff role is whatever the game's internal policies say there is.
-
@faraday said in Staff’s Job?:
Unrelated -- one way to look at the permissions/role/title angle is Ares' roles system. Instead of simple flags like WIZ/ROY/JUD, Ares lets you define custom roles, each of which is granted permissions to certain commands.You might have a builder role that can build/desc/teleport around. You might have a wiki staff role who has permissions to manage wiki pages, or app staff who can view apps and jobs.
It works great, though. I can build rooms on request (I am a professional copywriter, short prose is what I DO) without taking on other responsibility. Go, Ares.
-
Clearly there is enough disagreement as to what staff is or isn't that it might help if games, as individual entities, have a statement detailing what staff IS or ISNT.
Define it at the game level.
Head staff states what they're looking for from staff, then posts what staff IS and ISNT to the players. Everyone is on the same page. Boom.
-
As a ST I actually started to directly ask my players what forms of recognition/reward were most meaningful for them, and even share examples of interactions/rewards they've received elsewhere that were especially memorable. If my place actually gets off the ground I actually want to incorporate that in the CG questions.
True, sometimes people wont say or will get offended that you cant guess, but honestly when people have been open with me, getting to incorporate what speaks to them in a plot/scene is one of my favorite and sustaining things.
The only issue is volume. I do know people who seem to be able to regularly sustain 10-15 person scenes and feel like they were able to give something to everyone, but that's a gift I do not have. It is one thing to do it for a special occasion (epic battle, ect) which I think just has to happen sometimes and can be great fun in and of itself, especially if you are bringing smaller groups together. But for me even with extensive notes on each pc I find it hard to feel like I'm connecting well enough without smaller interactions (for me the magic number seems to be 4-8 for getting to know the players/pcs)
-
@faraday said in Staff’s Job?:
@Pandora said in Staff’s Job?:
If a game goes down, who do players look to? Staff. If there is a disruptive theme breach? Staff. If a plot conclusion needs a game-wide emit? Staff.
I just disagree, sorry.
You're not going to look to build staff if there's a disruptive theme breach, but these people are still staff.
The question was 'Staff's Job?' not 'Head coder's job?' or 'Build staff's job?' or 'Storyteller staff's job?'
@Thenomain said in Staff’s Job?:
Splitting off from the other recent discussions, what in general is staff’s job?
Of course you can break staff down into subgroups - the same goes for most any job with more than one aspect. If asked for the definition of 'McDonald's Employee's Job?' would you say 'It's impossible to say because there's no universal constant, some people flip burgers, some take orders, and some are CEOs making millions a year.'
Or would you say, 'People doing the tasks required for the McDonald's Corporation to keep making money.'?
-
@Pandora said in Staff’s Job?:
Or would you say, 'People doing the tasks required for the McDonald's Corporation to keep making money.'?
Actually I would say "people hired by McDonalds to do some kind of job" because that is literally the definition of employee.
But sure, we could apply that same definition to MU staff to say "people 'hired' (appointed might be a better word) by a game owner to do some kind of job'." Or to use something closer to your words: "People doing any variety of tasks that the game owner deems necessary for the game to operate."
Which seems remarkably similar to what I've said:
The only distinction between a non-staff role and a staff role is whatever the game's internal policies say there is.
What I object to are more specific descriptions that include things like "people the players go to" or "tasks that players don't have access to" or "people driving the direction of the theme/game", which I believe are too narrow to be a good definition for "staff". Yes, some staff on some games do these things, but they are examples, not universal constants embedded in the definition of "MU staff".
-
If I had to define what I think a staffer is, my perspective is this:
What staff think they are: Fellow community members who maintain a playspace that most of them would also like to partake in, but issues of being busy staff-side or difficulties surrounding being "staff-alts" tend to interfere. Games need game owners, and games need staff, so they open and maintain the theme park and keep the hobby alive. A small percentage have the time and code knowledge to do so, so they ultimately bite the bullet.
What players generally think of staff as: Custodians of the playspace, facilitators of character and job approvals, and overall responsible for maintaining the playspace in a way that allows them to have as few roadblocks as possible for whenever they want to utilize the service. Staff participation and enjoyment is generally considered secondary to the above, because staff chose to fill that role, and it's not the player's responsibility to facilitate anything unless they choose to.
-
@faraday said in Staff’s Job?:
@Thenomain said in Staff’s Job?:
what is staff's job in general? What is it to staff? What is it to not-staff?
Each game is going to have a different definition for this, so I don't think there is an "in general".
Then that's your general response.
Easy.
--
@Tinuviel said in Staff’s Job?:
@Arkandel said in Staff’s Job?:
I don't know how to teach someone to be a better decision-maker, to engage people or to be a better communicator
Me neither, and they let me have children.
How dare you exemplify that "can" doesn't mean "should".
-
@Ghost said in Staff’s Job?:
Head staff states what they're looking for from staff, then posts what staff IS and ISNT to the players. Everyone is on the same page. Boom.
This is actually something that we came up with too. I think it's a good idea to define what Staff believes Staff's responsibilities are, because then players know what to expect. They can define how much metaplot they'll be providing, how much theme-custodianship they'll be enforcing, etc. Players can see how PrP-dependent the game will be, how theme-strict it will be, and whether they want to play there.