Communications

hyperpape · #1

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.

Is there some human being checking each and every email address that the AGA has on a regular basis?
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?
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 · #2

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 · #3

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 · #4

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 · #5

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 · #6

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 · #7

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 · #8

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.

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

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

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

vash3g · #9

[*] 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 · **#10**

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 · **#11**

vash3g wrote:

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 · **#12**

vash3g wrote:

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 · **#13**

xed_over wrote:

vash3g wrote:

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 · **#14**

oren wrote:

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.

oren wrote:

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 · **#15**

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.

oren · **#16**

msgreg wrote:

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 · **#17**

msgreg wrote:

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 · **#18**

vash3g wrote:

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.

Quote:

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 · **#19**

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 · **#20**

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.

Communications

Who is online