From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Cross Subject: Re: Incident tracking Date: Fri, 28 Feb 2020 12:00:32 +1100 Message-ID: <87k147zftb.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44696) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7U1A-0003IY-O6 for emacs-orgmode@gnu.org; Thu, 27 Feb 2020 20:00:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7U19-0004Z4-Gz for emacs-orgmode@gnu.org; Thu, 27 Feb 2020 20:00:40 -0500 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]:40184) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j7U19-0004Wj-8L for emacs-orgmode@gnu.org; Thu, 27 Feb 2020 20:00:39 -0500 Received: by mail-pg1-x535.google.com with SMTP id t24so580209pgj.7 for ; Thu, 27 Feb 2020 17:00:39 -0800 (PST) Received: from tim-desktop (220-235-188-166.dyn.iinet.net.au. [220.235.188.166]) by smtp.gmail.com with ESMTPSA id y18sm8103270pfe.19.2020.02.27.17.00.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2020 17:00:36 -0800 (PST) In-reply-to: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org This is a fairly open question with a wide range of possibilities. If there is an existing incident management workflow, I would probably start by seeing how that could be replicated using org-mode facilities. I would start with a new org file and begin by listing your functional and non-functional requirements. Perhaps assign a priority to each requirement or use something like MoSCoW prioritisation to each (Must, Should, Could, Wont) to each. Then go through all the Must requirements and see how best to use org to satisfy them, then the should, etc. If you wanted, you could then come back to the list and show the requirements and your proposed org-mode solution or ask for an org-mode based solution and you may get some more substantive responses. As it stands, the possibilities are too broad/open for any real advice. A lot will depend on what or how you want to use the incident tracking system. For example, a priority might be just in tracking and responding to incidents or it might be to report on incidents or using the incidents to build up a knowledge base to help resolve incidents faster by making it easier to find known solutions, identifying reoccurring incidents that identify underlying problems etc. Org provides most of the key building blocks, but you may need to put some effort into reporting and summarising data. I would try to keep it fairly simple to start with and add functionality as it becomes evident it is required. Areas which will likely be good starting points might be - Capture templates. Standardising how data is captured will really help in further processing and reporting. Capture templates can be really useful for this. - Custom TODO states. You probably need TODO states which are more 'natural' for incident management. For example, instead of TODO, STARTED and DONE, you may want to define something like NEW, CONFIRMED, TRIAGED/FIX, RESOLVED etc. Any existing incident management workflow will likely provide good choices. - TAGS are likely going to be critical for classification, assignment and reporting on incidents. My only advice here would be to be conservative when it comes to creating new tags. Too many tags is often worse than too few. - Assigning unique ID numbers to each incident. You will likely have repeat incidents or multiple incidents with the same unerlying cause. Being able to link incidents or define relationships between them will likely be useful. It may also be worthwhile looking at some existing incident management solutions. Some of these have good ideas and may provide some valuable guidance. In many cases, the same principals can be implemented in org without too much effort. Lawrence Bottorff writes: > What would be the best way in the Emacs org-mode world to "keep track" of > "incidents" that might happen in, e.g., a factory setting? Let's say a > piece of equipment has various things in its life that happen to it: > breakdown, warning, maintenance, etc. that you want to keep track of in an > org-mode way. Would it be something in the TODO/GTD realm, or something > custom? > > LB -- Tim Cross