[-- Attachment #1: Type: text/plain, Size: 373 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 443 bytes --]
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
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
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
[-- Attachment #1: Type: text/plain, Size: 2085 bytes --] I can see that an "incident" can be seen as a TODO; indeed, anything event can start as a TODO, then move on in status to one of your other org-todo-keyword entries. Question: When I start the TODO process, and then update the status, once or more times, finally, perhaps with DONE, is there a record of this "Werdegang," this process? On Thu, Feb 27, 2020 at 7:50 PM Samuel Wales <samologist@gmail.com> wrote: > 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 > [-- Attachment #2: Type: text/html, Size: 2672 bytes --]
Lawrence On Fri, Feb 28, 2020 at 09:26:06AM -0600, Lawrence Bottorff wrote: > I can see that an "incident" can be seen as a TODO; indeed, anything event > can start as a TODO, then move on in status to one of your other > org-todo-keyword entries. Question: When I start the TODO process, and then > update the status, once or more times, finally, perhaps with DONE, is there > a record of this "Werdegang," this process? You can set Org to capture the timestamp when you change the item to DONE. As a consultant I frequently timestamp all of my work by inserting an inactive timestamp each time I switch tasks or return to the computer. That way in the agenda view I can review what happened and when. If you are more interested in automated time reporting, Org has options for that too. See clock-in and clock-out. ------------------------------------------------------------------ Russell Adams RLAdams@AdamsInfoServ.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3