* Re: Incident tracking
2020-02-27 22:55 Incident tracking Lawrence Bottorff
@ 2020-02-27 23:28 ` Russell Adams
2020-02-28 1:00 ` Tim Cross
2020-02-28 1:50 ` Samuel Wales
2 siblings, 0 replies; 6+ messages in thread
From: Russell Adams @ 2020-02-27 23:28 UTC (permalink / raw)
To: emacs-orgmode
On Thu, Feb 27, 2020 at 04:55:30PM -0600, Lawrence Bottorff wrote:
> 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,
You can structure your file any way you like.
You might consider either:
----------------------------------------------------------------------
- Organize tickets by time, adding to the bottom, but tagging them against
machines by serial or something similar
* Tickets
** TODO Fix it again :MACHINE_X:
** DONE Eat a sock :DRYER_2:
----------------------------------------------------------------------
- Organize tickets by machine first, then time
* Tickets
** Machine X
*** TODO Fix it again
** Dryer 2
*** DONE Eat a sock
YMMV. You can do reporting on either with column views.
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/
Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incident tracking
2020-02-27 22:55 Incident tracking Lawrence Bottorff
2020-02-27 23:28 ` Russell Adams
@ 2020-02-28 1:00 ` Tim Cross
2020-02-28 1:50 ` Samuel Wales
2 siblings, 0 replies; 6+ messages in thread
From: Tim Cross @ 2020-02-28 1:00 UTC (permalink / raw)
To: emacs-orgmode
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 <borgauf@gmail.com> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incident tracking
2020-02-27 22:55 Incident tracking Lawrence Bottorff
2020-02-27 23:28 ` Russell Adams
2020-02-28 1:00 ` Tim Cross
@ 2020-02-28 1:50 ` Samuel Wales
2020-02-28 15:26 ` Lawrence Bottorff
2 siblings, 1 reply; 6+ messages in thread
From: Samuel Wales @ 2020-02-28 1:50 UTC (permalink / raw)
To: Lawrence Bottorff; +Cc: emacs-orgmode Mailinglist
i have no right to respond as i have 483 scheduleds and 28 deadlines
and i get lost even trying to get one thing done per week, but i just
wanted to add to the advice so far.
there is org-edna for dependencies. org-depend also, but i think it
lacks the feature of scheduling a remote org-id header once a local
one is doneified.
it is useful to stick inactive timestamps at boh on headlines, so you
can do all sorts of things like visually bisect to find what you are
looking for, search only the visible headlines, etc. this makes for
good logging. [others will recommend date trees instead.]
i like this type of discussion as we have had few of them in the last
8 years or so and there is much insight for usage and even fodder for
better features or refactoring, i think.
gtd is too labor-intensive for myself, but others will suggest reading
materials if you think it fits.
org is flexible so it's really a toolkit for figuring out your own
structures. i'd suggest not getting too fancy at first because yagni
sometimes applies.
===
i find it useful to think of my org forest as an ontology of
representations of preferably physical objects that become canonical
locations in it.
thus, your washer is one holon [subtree] and you always know where to
refile to for it. then you don't need tags as much; you can use org
id links to make the forest a digraph. location determines identity.
this is in contrast to, for example "stuff to do for maintenance".
--
The Kafka Pandemic
What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
^ permalink raw reply [flat|nested] 6+ messages in thread