Hi, I also prefer to use a suffix(if not a phase 1 filter), then it is easier to see which object that has been changed when patching and upgrading. Easy to sort on the name, and then see which object that has been changed.
As you mention, with version 7.5 it may be easier to track changes using the modification tracking.... -- Jarl 2009/11/24 Tony Worthington <tony.worthing...@kohls.com> > > ** And I prefer to append a suffix to modified ITSM, after disabling the ootb > workflow, so that it sorts with the rest of the workflow but can be > identified easily. I use a prefix if the work is custom. > > A million ways to skin the cat. I'd be interested in hearing some creative > uses for packing lists or other 'new' features (object modification tracking > anyone) to manage customizations and the ITSM7 patching process. (A bit off > topic.) I have some ideas but most have proven too unwieldily to manage. I > guess when put into the context of patching ITSM7 though it's easy. :-) > > Tony Worthington | Sr. Technical Analyst | Kohl’s Department Stores > N56 W17000 Ridgewood Drive | Menomonee Falls, WI 53051 | office: (262) > 703-7763 | e-mail: tony.worthing...@kohls.com > > > From: Roger Justice <rjust2...@aol.com> > To: arslist@ARSLIST.ORG > Date: 11/24/2009 12:07 PM > Subject: Re: Naming Standards > Sent by: "Action Request System discussion list(ARSList)" > <arslist@ARSLIST.ORG> > ________________________________ > > > Great suggestions. I add a special character + at the beginning of the > string. This automatically lists the newly created workflow first. > > > -----Original Message----- > From: Lyle Taylor <tayl...@ldschurch.org> > To: arslist@ARSLIST.ORG > Sent: Tue, Nov 24, 2009 1:02 pm > Subject: Re: Naming Standards > > > ** > I’ve seen several naming standards, and lots of passion around some of > them, but most of the ones I’ve seen are too complex and, IMO, > unnecessary. My preference is to keep it simple and readable without > trying to embed too much information into the name. Generally, I do > something like this: > > <prefix>:<descriptive name> > > <prefix> is something specific to your organization that groups all of > your custom workflow together. That way, you keep all of your stuff in > one place, and it’s very easy to see what’s OOB and what’s yours. The > prefix may also be more than one level, kind of like this: > <prefix>:<app>:<descriptive name>. That helps to group related > workflow together. For active links, I may even have a third level to > indicate the primary form they’re with, but not always. > > For example, I might have something like this: > > LDS:MIRS:Config:Load Configuration Settings > > In this case, I have three prefixes (probably the most I would > generally have). The first one says it’s for our organizations. The > second one is the app it’s associated with. And the third one is the > form it’s for (the configuration console). The primary reason for that > is that I have a group of workflow related to that form, and this makes > it easy to view and work with as a group. That’s not strictly > necessary, since you can view by or filter by the primary form, etc., > but this works well for me. > > I use two different prefixes for the organization, one for completely > custom workflow, and another for modified OOB workflow where we > disabled the original and copy it to a new object and modify the copied > object the way we need. For example, if I want to modify the following > active link > > HPD:INC:DetailsCurrentIncident_100_OpenDlg > > I would copy it to > > LDS_HPD:INC:DetailsCurrentIncident_100_OpenDlg > > And then disable the original and modify the copy. Using the > underscore makes it obvious that it’s modified OOB workflow rather than > our custom workflow. That’s important when you’re patching the system, > and you need to know what you’ve modified so you can verify that the > patch hasn’t broken something, or if you can now undo something you did > before, because the patch fixed the issue you were working around. > > For the last part, I prefer not to try to embed all kinds of things > like the execution order, details about what the active link does, > etc. They tend to make the names cryptic, and don’t add much useful > information from what I’ve seen, especially given the tools we have to > work with now. In addition, since names can be quite long, I generally > don’t abbreviate words much, and often include spaces in the words. > The description I use usually is a short description of what the active > link accomplishes or what triggers it. I often use the latter for > active links attached to buttons, etc. That works well for me, because > I generally have the practice of having a single active link on the > button that then calls a guide to do the work rather than having a > bunch of active links on the button with different execution orders. > I’ve found that works better for me. > > So that gives me names like this: > > LDS:MIRS:Console:Check Required Fields > LDS:MIRS:Console:Clear Form > > Or > > LDS:MIRS:Console:Cancel Button Clicked > LDS:MIRS:Console:Assigned Group Entered > > Occasionally, I will add additional information like sequence numbers > of there are two pieces of workflow that are conceptually together. > That is, there is conceptually one action being done, but it needs to > be done in two steps. Like this: > > LDS:MIRS:Console:Lookup Assignee_1 > LDS:MIRS:Console:Lookup Assignee_2 > > Looking up and validating the Assignee takes two active links to > complete (one to do the look up, and another to verify that it > succeeded), and since they’re intimately tied together, I give them the > same name with a sequence number. > > I occasionally use underscores in the name when I want to visually > separate two parts of a name, like this: > > LDS:MIRS:Console:Required Field_Assigned Group > LDS:MIRS:Console:Required Field_Assignee > > The first part of the name indicates what it’s about (in this case, > validating required fields), and the second part after the underscore > indicates the field I’m validating. Doing it this way groups the names > together in the list and still makes it easy to see the two different > parts of the name. You could just as easily use some other separator > that stands out to you as well. > > So, in general, I don’t get much more complicated than that, because I > don’t see much value in many of the complicated naming conventions I’ve > seen, including the ones used by BMC. That said, a large and > complicate application or set of applications (e.g., ITSM) could > benefit from a rigorous naming standard, but I’m not sure it needs to > be as complex as what they’ve used in the past. Embedding too much > information in the name just makes it hard to read, and harder to > maintain. For example, if you include the execution order in the name, > you’ll need to renaming the object if the execution order changes. > That has resulted in a large number of active links and filters in the > ITSM suite where the name doesn’t match how the object is currently > defined. > > Well, that’s my philosophy. Others have very different ones, and they > may appeal to you more. Good luck. > > Lyle > > > > From: Action Request System discussion list(ARSList) > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
