When an admin checks the tech...@crisiscommons.org and sees a new
request, which will be tagged with the "Request" label, they should
"claim" that request as theirs by tagging it with their own personal
label (create your label in the tech-aid email account if it doesn't
exist yet.) That way other admins will not work on the same request.
Once a request has been claimed the admin should follow the steps
below to categorize the request and take any necessary actions.
Categorization Process:
Is it a technical request?
no: out of scope
yes: Is there already a similar project?
yes: [ROUTING] routing contains feedback from requestor step
Is it Finished?
In Progress?
Route to the project group
no: Convert to technical terms (will probably require
communication with requestor)
Once again check to see if there is already a similar
project, if it's finished or in progress, etc.
Initiate New Project as a technical request:
admin labels email as "Handled"
admin Posts details on crisiscommons wiki (cc) and
creates new project wiki
link to wufoo request
admin only fields available for further
categorization and additional notes
crisiscommons responds to request
create new wiki entry for project
store info to crisiscommons wiki and CRM of
volunteer base
Defining what goes on the wiki [ROUTING]
1. CC wiki section for this project: project title, technical
description of project, summary of technical resource needs
2. Project wiki: everything from 1 plus the Wufoo form exported,
converted to project wiki format, and pasted in
I would imagine it working something like this:
1. User fills out Wufoo form, presses "Submit."
2. Email goes to FogBugz and creates a new Issue in the TechAid
section
3. FogBugz automatically generates a "New Issue" email and sends it
to... this list perhaps?
4. Somebody from the list logs in to FogBugz and tackles the ticket.
The advantage is that you can use the status of the ticket in FogBugz
to avoid stepping on each another's toes. I don't know whether this
would complicate things too much, though. Please let me know what you
all think.
-James
On Jan 28, 12:07 am, Son Tran <son.n.t...@gmail.com> wrote:
> There shouldn't require one for the google group but the techaid email
> address for crisiscommons needs one
>
> S
>
> ...by way of my iPhone.
>
> On Jan 27, 2010, at 11:46 PM, maugus7...@aol.com wrote:
>
> > Hi,
>
> > What is the login for the google group?
>
> > Mike Augustine
>
> > -----Original Message-----
> > From: Son <son.n.t...@gmail.com>
> > To: TechAid <techaid-cr...@googlegroups.com>
> > Sent: Sat, Jan 23, 2010 8:54 pm
> > Subject: REVISED - Instructions on managing TechAid workflow
>
> > Requests will be submitted as Wufoo forms and for each request an
> > email will be sent to tech-...@crisiscommons.org, which can be
> > accessed athttp://mail.google.com/a/crisiscommons.org. Contact the
> > coordinator for this project to get the login information for this
> > email account and for the Wufoo form. Tech-Aid admins will check this
> > email account to examine new requests and decide what action to take.
> > Possible actions are to deny the request, route the requester to an
> > overlapping project that already exists, work with the requester to
> > convert their business requirement request to a technical resource
> > request - if necessary, or approve and initiate a new project.
>
> > When an admin checks the tech-...@crisiscommons.org and sees a new
They (TiA) have lots of translators who were not tagging incoming
requests as theirs as they came in, so they needed ticketing, and they
need to track translations.
In looking at tracking systems, they chose Open Atrium, because:
1. Fogbugz hadn't been donated at that point
2. Open Atrium looked similar to LightHouse
(http://lighthouseapp.com/) which had, they felt, an easier to use
interface for their purposes than Fogbugz; Fogbugz they thought would
be confusing for translators to use, who are primarily non-techies
3. Open Atrium was already up and running
I'll ask:
* If we do decide we need tracking, how long will it take us to set
tracking up? Would it be easier or worth it set it up now, instead of
wait?
* Do we gain/lose anything by using the same/different apps across
CrisisCommons?
Finally, I've heard that Noel is concerned about the legalities and
potential tax liability of donations of commercial products/services
to CrisisCommons, which seek non-profit stats, which also figured into
the choice of Open Atrium.
--
Doug Emery
Emery IT
443-831-6700
You can use a Wufoo template to set the subject of the email to "New
Project Request: {entry:Field15}" (Field 15 is your field labeled
"Propose a Project Name for Your Request.") You'll also want to set
the sender to some email address that is a member of this list.
Those who want to be gatekeepers for projects just pick off threads
that look like "new project request: ___" from this email list.
Et voilà!
On Feb 1, 6:05 pm, Justin Hayes <justin.a.ha...@gmail.com> wrote:
> I think that its an alternative worth discussing. But it might be overkill
> for our needs, at least at this point. All we really need is a way for
> someone (the term we chose is "gatekeeper") to claim a submitted request as
> their own. While I'm sure FogBugz can do a whole lot more than that, if we
> don't need to use all that extra functionality then adding it would just
> complicate thimgs, as you say.
>
> The existing scheme where we have an gmail account that all gatekeepers
> share and they are able to claim incoming requests by simply labeling the
> incoming email with their own personal gatekeeper label is sufficient. When
> a new request comes in from Wufoo to this gmail account a filter
> automatically sends a 'heads up' email to another account - currently my
> personal one since I am the official gatekeeper; but I think it makes more
> sense to have that 'heads up' email go to this google group.
>
> That's all the workflow we really need at this point in the game. If it
> turns out that we start getting tons of requests coming in and there are
> several gatekeepers who end up having a lot of back-and-forths with the
> requesters, then we might need more workflow. No way to know right now
> if/how that will turn out though.
>
> Other thoughts?
>
> --Justin
>