Extending the journal feature

Workspaces Software (General)
1

We use dedicated Discourse topics, some tags and some conventions to track the status and progress of the Edgeryders’ companies projects (company-internal documentation here). This topic is to discuss what extensions to that basic journal feature are needed, if any.

Initial collection of ideas I have in mind for that already:

  1. Automating comment for status and field changes: A custom plugin could post these comments whenever a user updates the status-* tag or a field in the first post. The comment thread would then closely resemble how it looked in the Drupal version. It can be implemented with inspirations from the Discourse core “discoursebot” user. In addition, it would allow us to switch to a unified mode of updating a journal: simply edit fields in its first post, which would be a wiki. No strikethrough, no status-* tag editing etc… The bot would post a comment about the change and who made it, and also adapt the status-* tag on its own. Potentially, BBCode tags like [status]…[/status] would be introduced in the topic template to simplify this task for the software.

  2. Tag for reuse candidates: To mark projects that are esp. promising for reusing / recycling them, we might want to introduce a separate tag that would be assigned in addition to “project-dropped”. Such as “journaltag-reusable”.

  3. Tag for crisis mode: As a simpler replacement for the former “Attention needs” field in the Drupal version, we might introduce a tag journaltag-crisismode. Or something less strong to indicate projects that need special attention to be successful. Can be further emphasized with an icon in front of the title, like one of :bangbang: :triangular_flag_on_post: :fire: :bomb:. (The usual named codes like :fire: also work in the title.)

  4. Bringing back the “Attention needs” field: Maybe simply not needed, as there is a strong correlation with “project state”. In the Drupal based system, it encoded the level of care with which the project must currently be handled. If you are waiting for the client to react to a proposal it might be low (“awareness”); if the client is waiting for you to make a proposal, or if the project is active, it might be higher (“management: attentive”). In general, “awareness” denotes a passive state, “management” an active one.

  5. Profect lifeline diagram: Add a diagram to a pinned topic in category “Project Journals”, or to a custom admin backend page, that shows the lifeline of every project as it changes its status over time. Status changes would be tracked from post revisions. Embedding the diagram into a Discourse topic is somewhat complicated but possible via a third-party diagramming web platform and custom OneBox embeddings – see this discussion.

  6. Tag for project manager: By assigning tags like manager-matthias and changing them depending on who is project manager, we would (1) provide everyone the option to have an overview of the projects they are managing by visiting the corresponding tag page, (2) unify how field values are changed: by tag, not by editing a wiki. The wiki would only contain things that don’t change (client, client contact info).

2

Of these four ideas, I would say that the first four are cool, but probably not worth the effort. The diagram would be, I think, useful, but again when I did a lo-fi prototype in early 2017 no one seemed much interested. I, however, am strongly interested in keeping an eye on our pipeline.

3

Basically I agree. “1. Automating comments for status and field changes” is comfortable but 14-20 hours of work to implement. 2. - 4. are cool but just conventions that would not be observed. “5. Project lifeline diagram” is quite useful but also takes the most effort to implement.

But I just added “6. Tag for project manager” which I thing makes sense, and is zero-effort to implement (just documentation). So I’m adding that now. (Edit: Done. Implemented now in documentation and assigning the tags to the existing journals.)

Otherwise, we’ll have to see what we need while using the journals. Feel free to tell your perceived needs her … I can at least look for ways to make it happen with reasonable efforts …

4

Journals are the pipeline of our sales. There are big risks associated to letting the pipeline run dry. My need is to have a simple way to know what’s cooking, and what is stuck. Hence I think in terms of dashboards.

I think we, as a company, have a tendency to ignore the big picture. This is dangerous, and a side of our culture I do not like. No one looks at cash flow predictions, which is exactly the same thing as ignoring the Doomsday Clock. There is bureaucratic reporting, and that’s bad. But then there is important evidence, and we should not treat the two as the same thing.

I do not know how to change this. The default is: I become some kind of watchman. You defer to my calls. This is humiliating for everybody involved, as well as fragile (because if I make a bad call I have the potential to do damage). We can do better.