Communications

[oren]

As I see it, this is exactly wrong. The issues could be entered into the major heading (called a "Project" -- my example shows "AGA Membership" as the Project) by the requestor. Any of multiple AGA volunteers that have signed up for helping monitor the membership tasks could assign a specific person or assign to a different project if the original requestor miscategorized. In addition the receiver can subdivide the task and parse out others. Example: I can't respond to the membership number request because the database is down: Start a new sub task called "membership database is down".

I don't think you're disagreeing with me. I never said one person has to manage it, but a group of people does have to be responsible for making sure things don't get dropped from the system. Otherwise it will just fall into disuse as it gets ignored.

[vash3g]

With an issue tracking system, there is a status of each individual request available to those privileged, presumably. This solves a major issue that is evidenced by your question "who is not responding". With an issue tracking system, you would know before the "customer".

This is a first shot just to see the capabilities, we aren't yet at the point of determining access control. I think a big benefit will be visibility across the organization. Perhaps the Issues List or the Overview can be printed for each board meeting.

Who will maintain the system is certainly an issue. It is step 3 of the plan. To answer the question, we have to establish whether it can/should be set up in-house or not and what maintenance might be required. Following the plan laid out above, 1) evaluate, 2) summarize requirements and capabilities, 3) discuss with webmaster for set up options, 4) board proposal.

I'm not saying yet that this can and should be implemented. I'm simply on a path to evaluate the option(s) for the board to decide.

You dont need board approval for everything. You know who made the decision to do a new website? Not the board. This is a day-to-day issue handled at most by the president. Dont forget you need buy-in at every level of help of person youre assigning tasks to.

BTW: the person who would be setting it up would most likely be me. I am one of the server admins for old and new server. You run that by the webmaster and maybe something can be setup.

I still think youre overlooking the biggest problem: People.

Find the loose ends of communication, maybe solve some of the problems.

[msgreg]

You dont need board approval for everything. You know who made the decision to do a new website? Not the board. This is a day-to-day issue handled at most by the president. Dont forget you need buy-in at every level of help of person youre assigning tasks to.

BTW: the person who would be setting it up would most likely be me. I am one of the server admins for old and new server. You run that by the webmaster and maybe something can be setup.

I still think youre overlooking the biggest problem: People.

Find the loose ends of communication, maybe solve some of the problems.

All good points. Again, all I'm doing is a little up front investigation to determine capabilities. If the proposal is implement by the webmaster or you before it gets to the board: even better!

It seems to me, this is the best way forward. At the end of it, you'll have something solid that you can, with full information, reject if necessary.

If/when the organization gets big enough or another volunteer that takes over in your position wants to know what options are out there, there will be at least a summary of what we find.

Find the loose ends of communication

I was under the impression that the communication problem was systemic, ongoing, and happened across multiple volunteers. At least in my non-AGA experience, this is always an issue with volunteers. Again, I currently believe an issue tracking system will help find the loose ends of communication perhaps before the "public forum frustration post".

How nice would it be to get an email from an AGA representative saying "I see that you had a request two weeks ago on your membership number, I also see that the person normally handling that hasn't responded, but I can answer that for you."

[Yertle]

I am seeing "webmaster" being mentioned extensively here so I guess I better respond.

First I am finding out that "webmaster" is a very limited role and has almost no authority. The things you mention the webmaster should do/approve are mostly out of my control and not under my authority. I would like that changed but that is how things appear to stand at the moment (I never have been given who is responsible for what with the website, I should probably get in touch with vash3g at some point to at least partially enlighten me).

The problem you are addressing is real. When I took over there was over 4 months of unread emails and I spent several days apologizing to people. Whether this is the solution or not I'm not sure, I think the problems run a bit deeper than a simple tech solution can solve, though it may be worth pursuing anyway.

Our new content management system, which I really hope will go live in February, might also be a tool that can be used for this sort of thing. I am pretty experienced with Drupal these days and it would be more likely that I could help out if that was the platform.

[msgreg]

Don't worry, you're far away at step 3

There is a drupal module for Redmine, which gives me some hope that a hosted solution would still be accessible through Drupal (if that's the CMS the main site has adopted).

http://drupal.org/project/redmine

A custom "Contact Us" form for submitting requests might be the goal for integration.

I see implementation, if we get there, as multiple steps: adopting for internal use first, perhaps for a few months, then exposing it to the general public through a contact form. All the while continuing to evaluate it and tweak usage and reports. I've got a more detailed plan, but we're not quite there yet.

Obviously, the ultimate decision to use it would rest with those using it.

[daniel_the_smith]

I just want to stress that the only way a system like this will take off is if the individuals using it see the benefit and actually use it. With that in mind, we should probably get a list of current volunteers and ask them what would make their life easier before we go too far with this...

[msgreg]

Agreed. Please post what you find out. It might make sense to also ask those that might have been delinquent in responding, if possible. If you need help in asking, let us know what we can do.

[shimari]

Whoever pointed out the real issue is PEOPLE was totally correct!!! I read and respond to 4 or 5 different e-mail addresses for the AGA and AGF, and I delegate e-mails to another 7 or 8 addresses for people to respond to. Protocols, systems, software, all are totally meaningless. The only criteria is volunteers who will read and respond to messages, and believe me, they are very hard to come by! I ask everyone who volunteers to meet one simple criteria - tell me if you are no longer able to answer your e-mails, either temporarily, or permanently, and I will assign your job to someone else. I do have a lot of great volunteers, and I am proud of our response time at the AGF. It has not been anywhere near as good at the AGA. The simple truth is that many volunteers burn out, and stop responding. We try to deal with this by having multiple addresses on a filter, in the hopes that one of the people on it will respond. The truth is that without a single individual taking personal responsibility for answering things, many messages go unanswered. If you care seriously about any of these issue, volunteer to be responsible for a given job, and then stick with it.

[msgreg]

So what do you do to find those people? What do you do until then? What do you do when those people leave?

Sure, you can claim it's people. I agree that that is one solution that works. Please give us a process to install that solution. And how do you sustain it?

I totally agree that the best volunteers say "no" rather than silently don't follow through. Most people have periods of time where they can't contribute. And some jobs will not have volunteers available for some time. The goal is a system that covers those holes without burdening everyone with a new/different system.

Until we know how to get there, the suggestion is similar to "the best way to have a lot of money is to have a high income."

[daniel_the_smith]

Whoever pointed out the real issue is PEOPLE was totally correct!!! I read and respond to 4 or 5 different e-mail addresses for the AGA and AGF, and I delegate e-mails to another 7 or 8 addresses for people to respond to. Protocols, systems, software, all are totally meaningless. The only criteria is volunteers who will read and respond to messages, and believe me, they are very hard to come by! I ask everyone who volunteers to meet one simple criteria - tell me if you are no longer able to answer your e-mails, either temporarily, or permanently, and I will assign your job to someone else. I do have a lot of great volunteers, and I am proud of our response time at the AGF. It has not been anywhere near as good at the AGA. The simple truth is that many volunteers burn out, and stop responding. We try to deal with this by having multiple addresses on a filter, in the hopes that one of the people on it will respond. The truth is that without a single individual taking personal responsibility for answering things, many messages go unanswered. If you care seriously about any of these issue, volunteer to be responsible for a given job, and then stick with it.

Hm, do I know you IRL?

Sending mail to multiple addresses is a good first step, but then you fall prey to the bystander effect (everybody assumes someone else will take care of it). My ideal system would automatically assign incoming mail to an individual, so there's no question about who should be responding. But it would also be viewable in the system by anyone else volunteering in that capacity, and it would know to reassign to someone else if a response isn't sent within a day or whatever. If it's anything like the bug tracking software I use at my day job, a volunteer could assign a response to a more appropriate volunteer (if the message was sent to the wrong person, for example).

[msgreg]

I think Yertle mentioned Drupal (which is based on PHP). I've also found Hesk help desk software which is also based on PHP and MySQL and is very reasonably priced: free if you don't mind "provided by" links and messages, $40 one-time fee for a single installation. They have hosting plans for $20 per month. Most help desk software seems to cost about that per month per agent.

There also are a variety of help desk modules for drupal itself. I think the needs will be modest just to sumbit and keep up with "tickets", so I'm hopeful we can find something that will work, be maintainable, and not require too much additional infrastructure or knowledge.

Just an update on my research...

[msgreg]

One differentiating factor in many ticket systems appears to be "anonymous tickets". This is the ability for an email to a specific address to be turned into a ticket without the need to log on. In the AGA implementation for ease of use, I think this will be an important feature. I'll be looking for anonymous tickets as well as incoming email gateway. Here is a list of current systems I'll be weeding through. This is based largely on looking through the drupal site and seeing recommendations and links from there. Some of these are not specifically drupal based.

Drupal-based project management/ticket tracking
http://groups.drupal.org/node/17948

Support
Storm

Suggestions from discussion thread

CiviCRM - non-profit multipurpose tool - seems great.
Modules include:
Case management for clients and constituents. -- this is what we'd start with.
Online fundraising and donor management.
Online event registration and participant tracking.
Online signup and membership management.
Personalized email blasts and newsletters.
Report generation and template management.
Commons
Kanban
FengOffice (formerly OpenGoo)
Drupal STORM

Anonymous tickets:
Zendesk
Ubercart / Uberticket - http://drupal.org/project/uc_ticket
This module is integrated with Contact and Ubercart, but also offers Mail-to-Ticket incoming gateway.
Also, it is easy to configure (no dependencies).

[hyperpape]

What's the status of this?

[msgreg]

Still reviewing options, post specific or general offers of help if you're interested.