[rt-docs] Hi to all

[Roger Mastrude]

Kenn, I used to work down the hill from you, for the UC Berkeley
computing organization. I came in 1968 and left around 1984 to become a
consultant. Were you there during the time I was? 

I'm looking forward to reading your doco!

-----Original Message-----
From: Kenneth Crocker [mailto:KFCrocker at lbl.gov] 
Sent: Thursday, January 24, 2008 10:09 AM
To: Roger Mastrude
Cc: rt-docs at lists.bestpractical.com
Subject: Re: [rt-docs] Hi to all

Roger, Jesse, others,


	I'm Kenn Crocker. I work at the Lawrence Berkeley National
Library. My 
background is similar to yours, Roger. Started about 40 yrs ago wiring 
IBM collators, moved to programming, at 1 time a VTAM programmer. I've 
coded systems in over 25 languages. I was senior consultant for an 
international Consultant company, been a DBA for 12 years as well. Now I

relax and administrate Technical Services team here at the lab.
	Since my background is mostly mainframe, I lean toward
structured 
design and documentation. The documents I have attached are specific to 
audience and purpose. They are as follows:

	1) RT Queue Admin Guide; this document is geared towards having
the 
AdminCc watcher(s) act as the managers of a queue. They do not Create 
anything that is Global, that's the System Admin function. These Queue 
Admins oversee their queue by assigning/deleteing/resolving  tickets, 
running project reports of PArent/Child etc. relationships and other 
administrivia. They may create Queue specific scrips/templates. They may

NOT create Custom Fields as we don't want a bunch of CF's that redundant

in either name or function. They set up rights for their users.
	2) RT User's Guide; this document is geared toward the person(s)
that 
HAVE/SEND/CREATE requests.
	3) RT Review/Approvals & QA WorkFlow Design document; this
document 
presents the functional design of these types of workflow as specified 
by O"UR Standards of Change Management. They may not apply very well 
toward any other company, but they may serve as ideas and models to move

forward from.

	There you have it. Jesse, feel free to move these documents
where you 
see fit with whatever comments you feel appropriate.
	By the way, I'm due to retire in a couple years and am thinking
of 
doing some side work. If anyone likes my work, I'm open to references 
for some consulting work. Thank you.

Kenn

On 1/23/2008 4:45 PM, Roger Mastrude wrote:
> I'm Roger. Looks like there are only the 3 of us so far. Jesse, do you

> expect more? If so we might start working on stuff but not commit it 
> until our group is pretty much to size.
> 
>  
> 
> I'm glad to be here, because I've personally had a lot of trouble as
an 
> RT administrator for the County of Santa Cruz California. I'm not 
> complaining so much as level setting. I thought The Book was quite
good. 
> It was only when I had to go deeper that problems arose. Things would 
> have been better if I hadn't been a relative newbie to Perl and the 
> major tools we use. One reason I'm willing to put in some of the 
> (outrageous, I assume) effort of doing new documentation is that I
would 
> like some things clearly on the record, for my own use. For example, I

> had trouble understanding the details of rights. I had trouble in 
> configuration, determining whether I was setting global rights or
local 
> rights to an entity; the entity relationships weren't all clear to me 
> with respect to rights.
> 
>  
> 
> Let me tell you about myself, in as unvarnished a fashion as I can.
I'm 
> a programmer with 40 years of experience going back to the first IBM
360 
> mainframe in 1964. I've worked a number of positions; my preference is

> "systems programmer", i.e. tech expert who knows the bowels of 
> things.I'm also an English major from college, and an honors grad of a

> top-10 law school. Forgive me, please.
> 
>  
> 
> It seems that I've spent my whole like trying to teach others things 
> they may not want to know. I'm interested in clear, precise doco.
That's 
> why I'm here. I'm a fairly good, fast writer. Understanding the
concepts 
> well enough though, isn't necessarily fast.
> 
>  
> 
> I always think I'm really a top-down kind of guy, but things never
work 
> out that way. (I'm really a middle-out guy, who follows this general 
> plan: (1) Let's do it top-down. How hard could it be for geniuses like

> ourselves. (2) Oh shit, when we try to implement our elegant simple 
> plan, there are all these details that don't fit! Despair! (3) Let's 
> work on all levels at once and try to build the best stuff we can.
> 
>  
> 
> I suggest we start with some top-level issues.
> 
>  
> 
>    1. Jesse, what are the management objectives from this doco?
>    2. Who is it for? RT system admins? End users? Admins? All of the
above?
>    3. Let's outline the whole content structure.
>    4. Let's get a style defined. It should be professional, but look
>       beautiful I hope.
>    5. Let's gather all the RT doco we can find anywhere and pillage
it.
>       Stealing other people's ideas is the highest form of homage we
can
>       pay to them. Jesse started this with a mention that Ken Crocker
>       had a lot written. Ken, can we look at it? Ben Weser mentioned
>       doco. MIT has doco.
> 
>  
> 
> I can be kind of pushy, so I hope I haven't pissed you off. Please 
> respond on how you want to proceed.
> 
>  
> 
>  
> 
>  
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> rt-docs mailing list
> rt-docs at lists.bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-docs