Page tree
Skip to end of metadata
Go to start of metadata

Purpose

Situation

The concepts area is atm not ideally structured. We say it shouldn't be structure by status but the status is actually one of the main structure elements ... although most concepts are probably in the wrong status.

We want to structure by topic which is rarely done at all.

All in all we have a lot of valuable information in there but it is sometimes hard to find, and hard to use because the state and relevance is not always clear.


Goals

We want to have clear guidelines for the structure we can use to reorganize the existing concepts

We want to have clear guidelines for the metadata inside a concept. This will be mainly useful for new concepts

A guideline how we want to work with concepts which outlines the live cycle of a concept as well (this we already have partially)


Use cases

Please list here scenarios where you usually come in contact with the concepts and what issues you face with the current structure and information around the concepts:

  •   
  •      

Proposal

Concept

Structure

Now

We have roughly the following structure (Michael: hard to describe but I give my best)

  • Concepts M5
    • draft
    • approved
    • implemented
    • planned
  • Concepts - draft & approved
    • planned
  • Concepts - outdated obsolete or abandoned
  • Concepts 4.5
  • Documentation backlog
    • documented
    • implemented
  • App Week
  • i18n keys

Future

We want to have this instead

  • ideas / suggestions
  • drafts / implemented
  • outdated / discarded


Metadata

Now

We have the following data inside the concept

  • Status as label (this is defined but near to nowhere used)

Future

We want to have this instead

  • status (but for reals this time)
  • rejected
  • applied
    • date/version
  • type:
    • infra
    • QA
    • tech-dept
    • arch
    • ui





Etcetera

Open Questions:





  • No labels

8 Comments

  1. As an alternative approach to trying to come up with an ideal structure: maybe we should utilise the labels more rather than trying to come up with a strict hierarchy structure? Then the structure per se does not make any difference (it can be just an un-ordered list fwiw), but we make sure that there is an interface that allows to filter/group that pile/list by specifying the relevant tags. In such case I presume the basic set of tags has to  be easily accessible (in a form of a memo/cheatsheet or whatnot), maybe a custom macro could aggregate the set of available tags/label automatically.

    1. Could you give an example list of useful labels you would use atm?


      1. I think the ones that describe the status and those pointing to the creator and the epoch of creation could do. Also it might make sense to define some broad components of the product. Something like e.g.:

        • obsolete
        • applied
        • WIP
        • rejected
        • parked
        • flaming
        • %USERNAME%
        • for %MAJOR VERSION%
        • infrastructure
        • QA/Tests
        • architecture
        • feature
        • UI
        • ...
  2. Hard to summarize but I'll give it a go:

    Concepts usually belong to a fairly specific part/component of the system—though it can sit on various zoom levels (e.g. Security > Permissions > Jackrabbit ACLs)
    Plus occasionally, there are broader changes that span across the whole place, e.g. architecture, dependency-management, ops. There's probably one or two good sections for that too.

    But still for the major part of it, it should be fairly natural to align those concepts with the product (wannabe) structure.

    Then when you dig into one sub-part, you get to see some kind of ideation backlog relative to that part.
    —might let us ask ourselves (and give a vague idea) what are the next 3–4 concepts/features for one specific module/component/sub-part (pick dam, templating, or admincentral individually).

    On another note, concepts which were partially or fully realized are not concepts anymore; they should move to, and live/evolve along with the code-base. Being accessible knowledge "on the spot" for developers getting to know the product. We're terrible at that atm.

    My point is, concepts are short-lived. They should either move elsewhere when implemented, or be demoted to (obsolete) ideas/suggestions when they don't gain enough traction (—until exceptionally one rises from the dead). This could be done organically by letting those ideas pile up; ideas are then promoted "above the fold" when accepted, selected (e.g. by PO), committed to. Only then they become concepts and must be brought to an end, then eliminated. Then repeat. (smile)

    1. I generally agree regarding the lifecycle of the concept, however, there are such concepts that aim to justify this or that technical decision and =>:

      • while we are willing to share more technical insights with the developers, but we probably do not want to share the reasoning behind our decisions (at least sometimes);
      • we still want to keep the concept around (indeed not necessarily around with "fresher" concepts) in order to keep track of our own decisions.
      1. Just as a sidenote: Concepts are in the "Magnolia Development" Space ... which is public (big grin)



      2. Don't we just search hipchat for decisions nowadays? (ninja)
        Fine to trim concepts to make them clearer; then it kinda calls for "archiving" the decision process part of it, so it doesn't pollute the conceptual inbox.

        One could argue as well concepts should intrinsically align w/ decisions, without explicitly tracking them (there's still a page history, if in need).

  3. I added some ideas to the concept I had the feeling we all basically agree on.

    But from the response I have the feeling only three out of over 20 PD members have an issue with the current chaos ... so I'm somewhat doubtful we can actually improve the situation with so little support :/ But lets see ....