Fwd: REVISED - Instructions on managing TechAid workflow

[Keith Berner]

It seems to me that we need a job description for the position of "gatekeeper."  We cannot let the definition of that job be "Justin Hayes," simply because he fell into it.  For our process to be truly replicable, it cannot depend on any individual or set of individuals.  Yet, I fear taking on the gatekeeper role myself , because I think that I am not techie enough, nor well enough plugged into this movement.   An objective job description that is divorced from personalities or particular cirises will help.

Keith Berner
7902 Flower Avenue 
Takoma Park MD 20912
home/mobile:301 588 5080 

Fight global warming — decide every day to reduce, reuse, recycle.

Begin forwarded message:

From: Keith Berner <k...@kberner.us>

Date: February 3, 2010 7:49:15 AM EST

To: "k...@kberner.us" <k...@kberner.us>

Subject: Fwd: REVISED - Instructions on managing TechAid workflow

--Keith Berner 

Sent from my phone

Begin forwarded message:

From: Justin Hayes <justin....@gmail.com>
Date: February 1, 2010 20:44:19 EST
To: techaid-cr...@googlegroups.com
Subject: Re: REVISED - Instructions on managing TechAid workflow
Reply-To: techaid-cr...@googlegroups.com

That's a good approach. We originally used the common gmail account because of the simple ability to claim via applying a label. One of the next steps in the Wufoo form is to try to add some invisible admin-only fields that can be used by admins to claim requests and store other workflow/state information during the new project creation process. Those admin-only fields combined with your suggestion for having it send straight to this google group (or perhaps another we create to separate out project requests from other TechAid communications) would simplify things and meet all of our needs.

On Mon, Feb 1, 2010 at 7:00 PM, James <james....@gmail.com> wrote:

Well, if you really don't want much workflow overhead, I might suggest
scrapping the GMail account and having Wufoo send directly to this
list!

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
>

> On Mon, Feb 1, 2010 at 5:52 PM, James <james.a.ro...@gmail.com> wrote:
> > Joel Spolsky has graciously offered to donate a FogBugz account for
> > CrisisCommons. I thought Perhaps TechAid would be a good thing to try
> > it out with.
>
> > 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
> > > > 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
>
>

[Justin Hayes]

There is a description of the gatekeeper role on the techaid project wiki page. It also contains the process that role follows. This should evolve as the project evolves. 

-Justin