Lounge

How to manipulate Moodle developers

 
This discussion has been locked because a year has elapsed since the last post. Please start a new discussion topic.
Picture of Don Hinkelman
How to manipulate Moodle developers
Group Particularly helpful MoodlersGroup Plugin developers
[adapted from a post by Brent Simmons. Might be useful reading in this beta testing--bug reporting time smile]

Imagine youre in my shoes: youre me, a Moodle Developer, for a minute. Think about feature requests, for exampleI have a list several hundred items long of really, really good ideas. Ive heard pretty much everything multiple times, though now and again I do hear new ideas. Which just makes the list longer!

Then of course there are bugs to fix, schedules to meet, tests to run, docs to update, user interfaces to design, lots and lots of things. Most of your time is spent just sitting in a chair, coding, because thats the only way things get done. (Oh, and then theres email. And writing blog posts. And so on.)

Okay, to put it in a nutshellthe input is like a firehose, and theres a ton of work to do, and both things are always true. So what do *you* do, the average Moodle user to manipulate me, the average Moodle developer, to do the things you want done. Here are some things that don't work sad and some things that do work cool .

Manipulative Things That Don't Work Anymore

The just one thing maneuver

This is the one where if I did just one thing then youd _____ (insert something good). This doesnt work because, well, I know you really want more than one thingor you will, anyway. And of course there are lots of people who want just one thingbut its a different just one thing for each person.

The I consider the lack of feature x a bug ploy

When youd like to see a feature, you cant make it happen faster by telling me you consider the lack of a feature a bug. Its clever, yes, but not the nth time. I really do classify stuff by bugs and features, and a feature really is a feature. (Yes, some features are obvious to-dos, but theyre still features.)

The surely it must be easy for a developer like you scheme

This one almost works, but Ive grown immune. (Slowly, over many years.) Very few things are easy. Quite often the coding is easythe actual coding is one of the easier parts of the job. Its the user interface design and software architecture thats harder. Many of the easy requests arent easy at all. (Some of them require advanced artificial intelligenceand raw computing horsepowernot seen outside the wreckage of the Roswell craft. Easy often means easy to a humanand, much as I love my Mac, no amount of ardor will give it human intuition.)

The maybe you should put it to a vote finagle

Ive learned not to take that as an insult. Its not meant that way. I used to think the person was besmirching my ability to determine whats best for the product based on what I think and the feedback I get. Ive learned that lots of software developers do in fact take votes from users, and thats coolits just that I get so much feedback already that setting up voting means more work with not much added benefit. I already know what people are asking for the most.

Being mean

Okay, this one is hugely rareMoodle users being the way they are. (Super-nice folks!) But now and again someone does come across as less than polite. It doesnt work. I take the bug or request seriously, but Im not going to give something a higher priority just because the person was rude. (Better to butter me up. Dont worry about going too faryou cant. ;)


Manipulative Things That Always Work

Now Ill tell you straight up the secret formula--how to manipulate me. Save me time. Time is so precious, its everything.

Saving time with bug reports

Consider bug reports. Whats the hardest thing about a bug report? Almost never is it actually fixing the bug thats hard. (Sometimes, but not usually.) The hard part is reproducing the bugthat is, understanding whats going on and being able to make it happen at will.

Once I understand a bug and can make it happen, I can fix it.

Good bug reports contain as much detail as possible and are specific. Generalizing and leaping to conclusions in a bug report is not helpful and is usually incorrect.

For instance, Ive had bug reports like this: The RSS feed doesnt support UTF-8.

Well, of course it does. I have no idea what the person is seeing and why he reports this bug. I end up having to play 20 questions, which is a waste of my time and his.

In the end we get it narrowed down to the actual bugwhich (for instance) is that the descriptions for a specific feed show as garbage characters rather than the expected characters. Imagine how it would have helped to know the URL of the feed and the specific problem in the first place!

The best bug reports follow this form:

1. What I did. (With as much specific detail as possible. Including URLs of feeds or URLs of weblogs when appropriate!)

2. What I expected to have happen. (Again, with detail.)

3. What actually happened. (With detail.)

Things like screen shots can really help, tooas long as you also use text to explain whats wrong.

(Why is step #2 important? Because some bugs are expectation bugs. That is, its working fine, but you expected something else to happen. Expectation bugs sometimes point to a user interface design or documentation bug. But not always.)

One other thing that can be super helpful is sending crash logs or error reports if something goes wrong. This can be done by turning on "debug" in your Admin configuration page. Debug is useful because it lets me know what the software was actually doing. No guessworkfacts, which saves me tons of time.

Saving time with feature requests

Most people think theyre like most other people most of the time.

And theyre rightexcept when it comes to software.

The first thing to know when writing feature requests is that, despite what your intuition tells you, despite your experiences in the rest of your life, you are not the representative user. You are specifically you, an individual, with your own ideas and needs and wants. (Its a Good Thing! Dont be scared! Im a doctor, and Im here to help!)

So... lets imagine a feature: Tuesday Whipper-Snapping.

It may seem obvious that Tuesday Whipper-Snapping is a slam-dunk. Surely its easy to do, surely every user wants Tuesday Whipper-Snapping, surely that would take the software to the next levelsurely its a bug, really, that Tuesday Whipper-Snapping isnt already in there.

Say I agree that Tuesday Whipper-Snapping is a good idea. I add it to the list: its now the 347th good idea.

The trick, though, is getting me to think its a super good idea.

The trick is not, as you might expect, to convince me that its something lots of people would want. The trick is to tell me how you would use it, how it would benefit you, how it solves a problem that you have.

Forget about other peoplelet me do any extrapolating. (Its my job.) Instead, just tell me a great story about how this feature would be cool for you. (It goes without saying, by the way, that its the just one thing you have to have. ;)

Also remember that, lots of times, software developers pay more attention to the problem being solved than to the exact feature being requested.

Think of ExposéI doubt the folks at Apple had feature requests that read like this, Please make it so that I hit a hot key and all my windows fly around and make it so I can mouse-over them and pick the one I want. Instead, they probably had feature requests like this: Please add a global window menu to the Dock so I can more easily pick a window from any app. They probably didn't listen to that, but caught the problem, "I have so many windows open, piled up on top of each other, that I can't find the right one!".

So they listened to the problem and came up with another solution, one that probably nobody had requested specifically, but that is really cool.

Sometimes that happens, sometimes not: Im just saying that telling a good story is important, because my goal is really to solve problem, not just implement specific requests.

If you tell me good, specific stories about you and the software and the problem you want to solve, then Ill know why the feature is important, and that makes it more likely Ill get to it sooner.



 
Average of ratings: Coolest thing ever! (10)
Picture of Howard Miller
Re: How to manipulate Moodle developers
Group Core developersGroup Documentation writersGroup Particularly helpful MoodlersGroup Plugin developers
Excellent post...

The bit about feature suggestions reminds me of an article I read recently related to cars. It argued that in the early 90s Ford started producing incredibly boring vehicles simply because they started listening to users too much. What users wanted, they said, was comfort, reliability, low running costs etc. So that's what they got. What they didn't get was any new, innovative, exciting features that the average user couldn't possibly have known about as the average user isn't in the business of building cars.

I hear it every day that we have to solve our user's real educational problems - but surely as developers we need (also) to be thinking about those new, exciting developments that will make all the difference to Moodle smile
 
Average of ratings: -
Picture of Helen Foster
Re: How to manipulate Moodle developers
Group Core developersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Plugin developersGroup TestersGroup Translators
Thanks Don - great! Please consider adding some/all of your post to the Moodle Docs page Bug tracker.
 
Average of ratings: -
Picture of James Phillips
Re: How to manipulate Moodle developers
 
I believe in musical terms this would be giving the audience what they need, not what they want. 
 
Average of ratings: -
Picture of Joseph Rézeau
Re: How to manipulate Moodle developers
Group Core developersGroup Plugin developersGroup TestersGroup Translators
> I believe in musical terms this would be giving the audience what they need, not what they want.
  • In pedagogical terms -> giving the students what they need, not what they want.
  • In political terms -> giving the people what they need, not what they want.
  • etc.

Problem is: who decides that what people/students/etc really need is different from what they want? thoughtful We have just had a good illustration of a rejection of this "enlightened despotism" in France with the calamitous First Employment Contract. See here.

Joseph

 
Average of ratings: -
Picture of Don Hinkelman
Re: How to manipulate Moodle developers
Group Particularly helpful MoodlersGroup Plugin developers
For me Brent's point is not needs vs. wants, but problem story-telling vs. solution-demanding. Even if a single person can explain their problem clearly, it can be more powerful than ten people who don't bother to explain their problem, but pre-judge a certain solution, and demand it.
 
Average of ratings: -
Picture of Osman Sadeck
Really Helping
 

It is sometimes difficult to decide what people need, unless of course these are generic skills that we can help with thru our postings and advice, courses , etc- Then there is the question of what people want- this will be informed by where we stand in how we consider we will help.

Are we givers of what people want that will  'empower ' or 'disempower' them? Tough decision - but what I find useful is the way some help others.

Perhaps as one posting mentioned we should be "focussed on technology, education and expanding the constrcutivist model"

We know that if you teach a person to fish instead of giving a fish you are empowering the individual---BUT lets remember that while the person is 'learning' to fish she/he needs to eat!

 
Average of ratings: -
Picture of Kevin Boutelle
Re: How to manipulate Moodle developers
 

Fantastic! I can't say thank you enough for that interesting bit of insight. I think that you're explanation of how you would rather be treated by pesky users is a window into the soul of many developers. You have given me a path with which to take with my own coders here.

Kudos, can't thank you enough!

 
Average of ratings: -
Picture of Juliette Culver
Re: How to manipulate Moodle developers
 
Good post. One of my friends also wrote an article on reporting bugs that echoes quite a bit of what you say on that front, that might be of interest to people too. 
 
Average of ratings: -
Art Lader
Server Info & Cpanel
Group Documentation writers
Good post! I have nothing to add, except that many people might not know where to get information about apache, mysql, etc. If they are on a shared server, they might have access to cpanel. In that case, they can  just look on the left for the info. (attached)

Where can they get this if they do not have a control panel?

-- Art

 
Average of ratings: -
Picture of David Cockayne
Re: Server Info & Cpanel
 
If you are on any server running php you can get masses of detail about your setup and config:

create a textfile
open it and type in:
<?
phpinfo();
?>

save with a .php extension then upload to your server
now view the file in a webbrowser, it will produce a big report about the server settings, versions and php options the server is using.
 
Average of ratings: -
Art Lader
Re: Server Info & Cpanel
Group Documentation writers
Re:
phpinfo();
 D'oh! wink

-- Art


 
Average of ratings: -
Martin Langhoff - Sailing
Re: Server Info & Cpanel
 
That's in Moodle's admin page, at the bottom. Did you look? wink
 
Average of ratings: -
Picture of Benoit Brosseau
Re: Server Info & Cpanel
 
good new is that if you dont want to learn command line interface or php scripting you can get a cpanel licence free if your in the education sector. Simplify the server maintnance for everyone including the admin because you dont get flooded with constant accounts creation request, etc.
 
Average of ratings: -
Picture of Charlie Wilson
Re: How to manipulate Moodle developers
 
I am currently a computer science major in college but i too have dealt with request from people for specific needs. I always love how to them it seems sooooo simple well how hard could it be to add one more button here... When in all reallity that one button requires umpteen lines of code and who knows what else. All of which takes TIME. I think that any time someone is developing software others need to understand that it takes time (it isn't as simple as we make it look HAHA). Especially if the software is to be developed right.

I personally am counting the days tell i get to take some classes in PHP and MYSQL so i can personally get into moodle and see what makes it tick. I know i could sit down and start reading books on php and figuring it out but between other classes the time isn't there. so i must wait for my chance to take a class.

Bottom Line... I feel ya brother.  
 
Average of ratings: -
Think I am older now :)
Re: How to manipulate Moodle developers
Group Documentation writersGroup Testers
LOL.  Truth is a wonderful thing and we know what Bliss is all about.  I say this as a user who in several former lives was a General Manager, MIS and software consultant.

Went to wikipedia and did a search on software bugs to put in MoodleDoc bug tracker page.   In addition to a picture of the first computer bug found in 1945, I also found a lenghtly  piece "How to Report Bugs Effectively at http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

I like Don and Bret's post which speaks from the heart.   Thank you for the post and reminder.
Chris. 

 
Average of ratings: -
Martin Langhoff - Sailing
Re: How to manipulate Moodle developers
 

This is so good, Don! We need a link to this in the bugtracker wink

 
Average of ratings: -
Picture of Ludo (Marc Alier)
Re: How to manipulate Moodle developers
 
At least there's a link in the wiki! smile
 
Average of ratings: -
Prince George, Cottonwood Island, royal coach
Re: How to manipulate Moodle developers
 
A delightful read and a useful tip.
 
Average of ratings: -