Anomaly Jobs: +myjob/cc
-
Not just pedantic, but aggressively pedantic. I couldn't think of a reason for it, either.
I may have taken it too far. Things have left me tetchy lately.
-
I will admit to being both pedantic and argumentative.
Out of the hooks used by aJobs itself, &HOOK_MAI is the only one that works on the comment that triggered the hook while OTH/CRE/CKI/CKO/APR/DNY/COM/AUT all work on the job itself or the first comment. Knowing this is not necessarily helpful but I think it does explain why the author thought it to be better to use %0/[last(sortby(%va/SORTBY_COMMENTS,lattr(%0/COMMENT_*)))] for MAI rather then pass the comment reference to every hook.
The good news is that if you want to change this behaviour, the only part of the code that currently triggers hooks is &TRIG_ADD so you could just extend &TRIG_ADD to pass the comment reference as a fifth variable and nothing should break.
Quite a few people have expressed in this thread and elsewhere that they'd like to replace aJobs with something else. I believe most of my frustrations with aJobs come from the inherent problem of trying to work with job tickets inside a glorified telnet client so what I'd like to know is, what do you wish aJobs did differently?
-
I wrote my own. This code, every time I look at it, is amazingly overcomplex. And I thought I was bad.
EDIT: I don't write 'public' code, and for many reasons, won't. Thus, my code does exactly what my game needs it to do, and isn't done in such a way as to be 'modular' or 'customizable'. I do not mean to deride the actual coding. I haven't peer-reviewed it, so I have no right to do so.
-
What people want out of +jobs that +jobs doesn't already provide: a professional, web-based bug/ticket-tracking system that is completely configurable and robust. IE, ZenDesk, Fogbugz, etc.
Honestly, I think aJobs is the best you're going to get if you go completely MU-based. If you wanted to give the people what they want, though: make there be a jobs code that has a web component which is accessible from within the game via SQL queries. Pay more attention to the web component than the MUcode component because that's what they care about.
Seriously though, the stuff people ask me to do to jobs is always "I wish it were a webpage" stuff. Sorting, searching, don't make tickets public except for users with X logins, allow group discussions in a ticket, make it send notices to my phone, yadda yadda. Every time they ask for a feature I miss the stuff I use at work.
MUs have already embraced wiki. Who's to say the next thing they go for won't be Bugzilla? (Although really that's not the best for this task... but it's cheap, at least!)
-
Honestly, I'd just like it to be simpler. Looking at the jhelp, I know it's not insanely complex from the end-user standpoint, but I still find myself fumbling over things.
I think this is part of why I, with a couple of exceptions like Myrddin's code, tend to write everything from scratch or adapt code I'd already written. I found an entirely serviceable version of the places code, but found it to be weirdly finnicky and so I rewrote it from the ground up. Of course, when I write stuff I write it to be a little simpler than a lot of what you'd find out there (I tend to find creeping fneeps an annoyance), and I tend to make heavy use of new features for Penn (much love for attribute trees and self-defined registers).
-
I have found that the out-of-box solutions for bug trackers php/sql solutions have been not sufficient because of:
- Privacy. Unless the system allows for 'private submissions' that are visible to the 'dev team' only and the submitter. Most systems default to submissions being public. Granted if it gives ability to create ACLs and Groups, it can be accomplished.
- With #1, there is rarely ability to add watchers and collaborators on submissions.
- IC Group management of submissions seems to be always an afterthought in the systems I reviewed, so letting your Vampire players submit and track non-work items (such as a sphere player todo list) is not supported.
On my last game, I started to build my own web-based @queue system that was also available in-game. In fact, this is why SQL support in Rhost was started.
-
@Rook The more I think about it, the more convinced I am that users want forums rather than bug tracking software. I can't see it being easy to find a forum software that fits those requirements either, but at least with that, private messages are an option. Maybe even private group messaging, which would take care of 1 and 2.
-
I don't want to derail this thread, but maybe we could talk about this idea.
-
@Rook I think that's what this forum exists for: derailing. XD I'm not up on my forum software and surfing the web isn't turning up much for forum software with "group messaging". It is apparently a thing, though - gaming forums use it for private Let's Plays. You know of any software that fits the definition?
Also, what is this site running? I like its functionality but it lacks group messaging - maybe we could hack it in with a plugin or source edit.
-
@Groth, @Melpomene: Your average musher/staffer isn't going to be a real life coder, or even in tech support. So while 'I wish it was web-based' might be helpful, I don't think (I could be wrong) that that is what the overall day-to-day user wants out of ajobs.
Some of the problems with ajobs:
-
It is really hard to customize unless you have some mu* coding experience. Your typical admin isn't going to be able to go in and change the permissions / mail defaults / etc for buckets for example. So if they want to set up a bucket of jobs that is public/visible to everyone in a sphere/group/etc so people can communicate through +job then someone is going to have to tell them how to lock a bucket to a specific sphere or players with a certain attribute, etc. Or they will need a coder on game to do it for them.
-
aJobs is really good for tracking an ongoing conversation. Every comment, every action, to the job is marked down. This can make long conversations between players and staff really easy. Have something to say but can't wait around thirty minutes for a response? Leave it in the job. You can come back and look at the response later. It's also
reallysomewhat good about notifications on the conversation. What with /mail and the * and 'new' statuses. It isn't very good at archiving those conversations for later. Unless you have an SQL / Web Forum Archive set up. Which not everyone knows how to do. @Thenomain has a tutorial up on this but I haven't attempted it, frankly, that's a bit over my head. So if I have a problem with it, I know other mu* staffers will. (Not saying I'm some genius but relying on the principle from my classes lately 'if you're confused, chances are someone else is too'.) -
aJobs is a somewhat okay system for tracking what staff (and sometimes players) should be doing. You can log in and say: 'Oh, someone wants to be approved to play. Let me look at their characters'. Or you can see that a player wants to have a conversation with you. On games where custom buckets have been setup for players who have extra "duties", they can log in and see: "Oh, JoeBob has requested a scene with X Y Z details. That sounds fun, let me do that!" or "Oh, SarahBeth is confused about wikifoo, I can help setup her wiki!". (Examples from darkwater, we had a special player & staff plot pocket where players who volunteered to be STs could see other player plot requests. And a bucket setup for staff & players for wiki questions / concerns, where we had players who volunteered to help with the wiki).
- ajob is not very good at organizing those things you need to do. Yes, it can say 'this job is overdue' or 'this job is labeled important'. But it doesn't have an easily accessible function to tell you: 1) how many jobs you have, 2) how many are overdue, 3) how many are new, 4) how many are by the same person, 5) what types of job each one is, 6) any other question you might have about those jobs.
-
aJobs is not good for immediate back-and-forth communication, but staff use it that way anywise in places.
-
aJobs is not good for private voting or private discussions were multiple people, but people use it that way anywise.
-
aJobs is not good for handling player complaints / concerns, but people use it that way anywise.
-
Frankly, aJobs (imo) is good for any sort of administrative 'i need x y z done', or 'lets talk about details of a plot' or 'can i have this'. It probably shouldn't be used for social issues, things that can be handled immediately, or private/sensitive matters.
-
-
@Cobaltasaurus
I make everyone use jobs because it's a good way to have things documented. But I, as staff, if I have the time, prefer to talk to people in pages about things and then just add the conversation to the job.
-
It is on my todo list to build a sql-based system that has both MUSH and Web interfaces. If I get some time, I might start a Code Code thread with the planned feature list.
-
@Coin said:
@Cobaltasaurus
I make everyone use jobs because it's a good way to have things documented. But I, as staff, if I have the time, prefer to talk to people in pages about things and then just add the conversation to the job.
Sorry, I guess my post was kinda preachy.
To be clear, I'm not knocking the people who do these things. There isn't a better alternative right now. But aJobs very often gets used for things it is not good at. aJobs is not very good at keeping things private between one player and one staffer, if that is a case that needs to happen. RE: The beginning TR jobs were VASpider and her ilk would read +complaint jobs that only HeadStaff was supposed to read, before they got custom locks put on the bucket.
The 'talk to the player and then document in job' is a pretty good method. Especially if you have an SQL archival forum setup because yes, documentation is really important on mushes. Considering the amount of staff turn over games get.
Another example: aJobs is a pretty poor place to store player "off-grid"/"out-of-scene" rolls. Not because of documentation but because it gets spammy. Until another system is coded to add to it -- where players can get a roll report inserted into the job, the roll results can be so spammy it's easy to lose track of what everything says.
I guess the big problem with aJobs is that it's not meant/not good at alot of the stuff that it has slowly been evolved/changed/morphed into doing over various games. People want a way to track rolls? Do it in a job! People want a way to track complaints? Do it in a job! People want a way to track battery-stat spends? In a job. Etc. etc.
-
Found one that looks like it would work as a front end: MyBB It's got the group messaging thing, it's free, and it's MySQL-based, so poof, you can write a MU front-end for it to help out those users who don't want to pop open a browser.
Personally I'd be happy with a system that notified me to check the forums on the game when something new came up. Maybe with links. No need to actually replicate the content in the game itself. But that's me, I'm not sure I use the game like a normal person.
@Cobaltasaurus I hate to say it, but it's precisely because users aren't coders that I believe they want a web-based, or at least web-like, solution. They take one look at aJobs' code and quit, and by default, it doesn't do exactly what they want it to, so they all want/need at least small changes. Forums and point-and-click are way more intuitive. No having to remember the typed-out commands, no confusion between staff role and player role jobs... and if it works right, you even get those phone notifications people like. Wheeeeee.
-
@Melpomene said:
@Cobaltasaurus I hate to say it, but it's precisely because users aren't coders that I believe they want a web-based, or at least web-like, solution. They take one look at aJobs' code and quit, and by default, it doesn't do exactly what they want it to, so they all want/need at least small changes. Forums and point-and-click are way more intuitive. No having to remember the typed-out commands, no confusion between staff role and player role jobs... and if it works right, you even get those phone notifications people like. Wheeeeee.
You're right. The average end user of aJobs would probably prefer a web-based solution. My point (which was worded extremely poorly, my apologies) is more that it isn't an active want that I come across. I don't have get people saying: "I wish this was web based", because most of them aren't in tech support/other custom service support rolls with a computer based webpage. So many of them don't know that there are fair better ticket tracking solutions out there -- just web ones.
However, I also don't have much experience outside of nWoD games were aJobs seems to be part and parcel these days, and so many nWoD staffers have all already staffed on other nWoD games, so they're all familiar with the +command side of the code, and I don't often hear the first impressions of +jobs.
-
What I find frustrating about working with aJobs is that it's so hard to maintain context, you'd think that having someone's sheet open, looking at a job and having a conversation in pages wouldn't be an exercise in frustration but it is.
Not to mention when you have several jobs on the same topic (For instance a plot that three different groups of players are working on) you end up having to copy paste the jobs into notepad documents, not ideal.
@Cobaltasaurus
The problem is that a lot of the issues you have with aJobs are things I believeare impossible to fix while still working with MUSHCODE.For instance take private conversations between staff and a player. On our game all members of staff are Royalty which means they have the SEE_ALL power, this is rather useful when it comes to helping people out with various things however it also means that no matter what sort of locks you put on something, all members of staff can read it by simply get()ing the data directly rather then using +job <x>.
The sensible thing to do I feel is to move the jobs system off the game objects and into the SQL database.
One of the dreams that I've discussed with @Alzie is to take one of the web based ticketing systems like Bugzilla and connect it to the same database as the game. Then players would be able to create and manage their tickets from the game but they'd also be able to get their tickets on their webbrowser/phone etc.
-
As the mighty starter of this thread, I bless anyone who derails it to discuss alternatives to aJobs. Because really.
edit: Belated praise, or re-praise: The jobselect system is the shiznit. It is non-stop awesome, and hooks in both easy and peasy, with some lemon squeezy.
-
@Cobaltasaurus said:
Some of the problems with ajobs:
- It is really hard to customize unless you have some mu* coding experience. Your typical admin isn't going to be able to go in and change the permissions / mail defaults / etc for buckets for example. So if they want to set up a bucket of jobs that is public/visible to everyone in a sphere/group/etc so people can communicate through +job then someone is going to have to tell them how to lock a bucket to a specific sphere or players with a certain attribute, etc. Or they will need a coder on game to do it for them.
I would say that being a coder or knowing mushcode does not make you able to modify ajobs. Ajobs is a beast of a thing that doesn't like to be messed with. Even if you do know mushcode and are a veteran coder to boot, Ajobs will chew you up and spit you out. That's how annoying it is. Really, the only people that know Ajobs are those poor souls who for whatever reason bring that soul crushing hell upon themselves willingly and work through the code.
.
RE: Web: I would think that the majority of players would rather not leave the game to put in tasks. On the other hand, our surveys have been popular, so maybe there's room for it. And wiki's are kind of standard now. -
@Alzie said:
I would say that being a coder or knowing mushcode does not make you able to modify ajobs. Ajobs is a beast of a thing that doesn't like to be messed with. Even if you do know mushcode and are a veteran coder to boot, Ajobs will chew you up and spit you out. That's how annoying it is. Really, the only people that know Ajobs are those poor souls who for whatever reason bring that soul crushing hell upon themselves willingly and work through the code.
I cut my teeth when I first began coding "seriously" (as seriously as I do anything mu*wise), on features for aJobs.