[rt-docs] Hi to all

[Kenneth Crocker]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RT Queue Admin Guide 364_copy.doc
Type: application/msword
Size: 601088 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-docs/attachments/20080124/188f2cfd/attachment-0045.doc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RT User Guide 364_copy.doc
Type: application/msword
Size: 1136640 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-docs/attachments/20080124/188f2cfd/attachment-0046.doc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RT_Approval_QA_WorkFlow_Design.doc
Type: application/msword
Size: 264192 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-docs/attachments/20080124/188f2cfd/attachment-0047.doc