Communications

[hyperpape]

Here's two old comments about communications, mostly about responding to emails. And the recent long thread started by bearzbear indicates that some people still perceive that there's a problem.

viewtopic.php?p=79208#p79208,
viewtopic.php?p=79215#p79215

I'm gonna target Daniel with these questions, because I know he'll read this soon, but there's probably multiple people who might be able to answer.

1. Is there some human being checking each and every email address that the AGA has on a regular basis?
2. If a volunteer becomes overwhelmed, or quits, do they know who to contact, or is someone specific responsible for making sure that a replacement can be found?
3. Are there clear and reasonable expectations about responding to email communications?

I think the second point is crucial. Volunteers need to be able to say "I'm about to get married, take a honeymoon, and then we have to merge our households. I'm not gonna be worth much this month." And when that happens, things shouldn't grind to a halt. Someone should at least check the mail and be able to say "

And the third is too. Not everything has to be answered, but quick responses like "yeah, we'll run that in the e-journal soon", "I'm not sure if there's any volunteers who can do that job--it may have to wait" or "interesting idea, but it needs some details/discussion" do a huge amount to make people happy (even "I'm forwarding the email to jimbob" is good enough). You don't need some written policy, because that way lies bureaucratic insanity, but you do want a shared understanding about communication.

[daniel_the_smith]

1. Usually, I think, but don't know for sure.
2. I doubt it, but am not sure.
3. Not that I've seen.

(Yes, this is a problem!)

I think a little automation could go a long way here, like bug tracking software, as mentioned by someone in that other thread. Just the automated "hey, we got your email and will respond within X days" would be extremely useful, especially if the system emailed another human if no response gets sent.

Can one of you recommend a system that accomplishes the above? I can certainly make an effort to get it implemented.

[msgreg]

Redmine and/or Chili Project are open source issue tracking systems that may apply. I've been looking at them for our small company's use.

It will need to be reviewed to determine if it can handle the communciations/projects necessary. Perhaps every email request can be siphoned to the dozen outstanding "projects" that are actually inboxes for the various AGA departments.

Just a thought. After I re-engage from my AWOL status with the AGA Web Update folks and fulfill any outstanding obligations, I could help evaluate such a system.

[hyperpape]

As I was writing a response, I warmed to a bug-tracking system. Think of each email as a ticket. (That doesn't necessarily work if there's confidential content anywhere). But there are limits to that:

Point 2 requires a human being with knowledge of who has what skills or who needs to hear a given question/request. I guess bug-tracking systems do facilitate assigning a bug to a given person.

Point 3 requires that when volunteers sign on, someone does orientation and stresses the value of responding so that people know they're not talking to a black hole.

[daniel_the_smith]

Point 3 I totally agree on.

For points 1 and 2, I think the most important thing is to get multiple people involved in responding to email inquiries, so that if someone drops the ball, others can pick it up, and to increase the chance that someone who knows who should see the item will actually see it.

[msgreg]

Just so everyone is on the same page, and we don't have to bother the board or other AGA volunteers with this project before we gather information. I think the results and cost are within reason enough to pursue without further board approval. Daniel or Andrew can comment on this plan if they wish. But I think there are the correct touch points to have the right balance of input vs. effort. If you have experience with redmine or chili project, please contact me or post on this thread as I'd like to ask you some questions and have a shot at determining how it would all work and what the capabilities might be.

I think the next steps are:

• Evaluate Redmine or Chili Project to determine capabilities and how email flows within it.
  
  • Do this with a free hosting service or set one up.
    
    • http://plan.io/pricing/ is free for 30 days or 9 euro per month for a basic hosting plan, or free for a single project. The 9-euro plan may not be enough to fully implement, but should be enough for a long term test.
    • http://www.hostedredmine.com/ is a free redmine hosting service.
• After evaluation, summarize requirements, capabilities, configuration, backup plan or options.
  
• Discuss with AGA Webmaster what the options might be for 1) setting up on usgo.org machine (based on OS, installed packages, etc), or 2) determine cost on hosting plan.
  
• With AGA Webmaster endorsement, summarize findings and plan for Daniel to take to board for capability vs. cost discussion and determination.

[daniel_the_smith]

You guys made my day, I'm really excited about putting together some sort of recommendation here. The next board meeting is the 12th, if we can get something together before then, I can get it in the meeting as new business.

I seem to recall my wife doing something with salesforce at a nonprofit she used to work at, and if I recall, it was free for that nonprofit. Perhaps that can be added to the list of things to look at. I'll try to take a look at Redmine and Chili Project later.

[msgreg]

Here's a test. I set up a Project called "AGA Membership", added a new Task "Requesting information", then briefly looked at how to list the tasks.

I think multiple AGA volunteers can be Project or Task "watchers", presumably to be notified when activity happens, or maybe so those tasks appear on reports made by that person. I'm not sure.

Here's what task input looks like. For ultimate user use, it would have to be much simplified as a "contact form" for the AGA website.

NewTask.png (67.51 KiB) Viewed 16032 times

Here is a list of tasks containing the one task I just added.

TaskList.png (72.85 KiB) Viewed 16032 times

Here is a detail list of the task, this would be what is viewed internally, perhaps also by the original requestor.

TaskDetail.png (95.77 KiB) Viewed 16032 times

Seems promising, but there are a lot of open questions such as access control, customizibility, and reliability.

[vash3g]

[*] Is there some human being checking each and every email address that the AGA has on a regular basis?
--What you dont know is that approximately half of the aga email addresses go to real mailboxes on the system, the rest are distribution lists sent to multiple addresses. For example tournaments@usgo.org is set to be received by 5 people. ratings@usgo.org is sent to 2 or 3 people (i cant remember).

[*] If a volunteer becomes overwhelmed, or quits, do they know who to contact, or is someone specific responsible for making sure that a replacement can be found?
--Most of the time if they quit they quit to the president and try and give information to him. We do have the wiki (http://wiki.usgo.org) where anyone can write things down for other volunteers to help out.

[*] Are there clear and reasonable expectations about responding to email communications?
--There are not! I received many emails saying "great, thanks!" even though i was looking for an answer to questions.

When I was webmaster I did try and respond to most emails. Approximately half-3/4 of them were instead sent to the database manager. FYI: the webmaster doesn't deal with member or chapter things, except for website hosting.
While I applaud every ones enthusiastism in making a contact form and help desk for the AGA, you may be over thinking this.

The first concern I have is who will be maintaining this system?
Who will have access to answer questions?
What happens when this fails?

I understand peoples communication issues, but who are we emailing that is not responding? If its a named person maybe we can bug the person above them on the org chart. If not i'll go see who is listed for that mailbox and let you know why it is not getting answered.

[oren]

I don't know about the other systems, since I haven't used them. A bugzilla system could be useful. That way when things pop up "The ratings are not being updated", we could actually search for it and know what the status is.

Whoever manages the system could assign the bugs to the right people.

[xed_over]

maybe we can bug the person above them on the org chart.

We have an org chart? Can it be made "public" (at least to those who are actually on the chart)?

[msgreg]

The first concern I have is who will be maintaining this system?
Who will have access to answer questions?
What happens when this fails?

I understand peoples communication issues, but who are we emailing that is not responding? If its a named person maybe we can bug the person above them on the org chart. If not i'll go see who is listed for that mailbox and let you know why it is not getting answered.

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.

[vash3g]

maybe we can bug the person above them on the org chart.

We have an org chart? Can it be made "public" (at least to those who are actually on the chart)?

http://usgo.org/org/documents/aga_organ ... hartv2.pdf

see also: http://usgo.org/org/information.html

[msgreg]

I don't know about the other systems, since I haven't used them. A bugzilla system could be useful. That way when things pop up "The ratings are not being updated", we could actually search for it and know what the status is.

Redmine / Chili Project does similar issue tracking to bugzilla. I'd love a volunteer to evaluate bugzilla or any other issue tracking system in parallel to my investigation of Redmine / Chili Project. Please report your results in this thread.

Whoever manages the system could assign the bugs to the right people.

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".

This methodology would help alleviate the burden on any individual volunteer (except of course where key volunteers are responsible for a specific item, such as the database).

This also helps any individual volunteer to see what tasks are on their plate at any given time just by pulling up their "issues list".

One goal, as I see it, is the system becomes a workflow management system, of sorts. Again, we'll have to see how it all works. But I think it's promising.

[xed_over]

I almost agree with vash3g that an issue tracking system might seem overkill, but on the other hand it does have its advantages too.

In particular, while on the tournaments list (but semi-retired from my volunteer duties), I often saw questions that were simple to answer, but never saw a response -- because the response might have been sent off-list.

With a formal issue tracking system, all volunteers could see which issues were still open and need to be addressed still.