Areas-based files with skills?

[dpb587-pivotal]

Hi - currently there's a areas.yaml and skills.yaml, but I was wondering if you'd consider having a single file per area which then includes the skills?

• It seems like skills are always in relation to a single area anyways.
• It would help keep the context between an area and a skill closer together.
• Areas can sometimes be within a specific context/team, so it would allow copy/paste/tweaking on a file level to capture the "area" + skills.

If interested, I'd be happy to PR the change.

[rosenhouse]

Interesting! I definitely understand how the current format negatively impacts the contribution experience to this repo.

Some additional context to consider:

• Currently we have some untested code (especially the add-on) that relies on the existing data format. Changing it without first adding test coverage introduces risk, though we could mitigate that risk in other ways.

• We'd like to leave room to capture new kinds of relations such as:

  • a skill "arc" which ties together a progression of skills
  • an engineering "persona" that draws on skills across areas
  • an engineering P-level that might be suggested by particular sets of skills at particular levels.

  It isn't obvious to me how best to represent those other relations if not in their own tables.

Thoughts?

[dpb587-pivotal]

Thanks for the extra context. I guess a lot of it comes down to what the basic "units" are. It seems like skills are considered the lowest level. From the perspective of feedback and reviews though, I think they apply to the tuple of a skill + persona, not just a skill. I also think those personas often apply within the context of a non-global domain. For example, "how is Danny as a Domain Expert in BOSH?" is different than in CF, Ruby, X.

From a schema brainstorming perspective, I imagine it as...

• skill { id, description, examples [{ example }] }
• level { id, description, skills [{ id, examples [{ example }] }] }
• persona { id, description, skills [{ id, examples [{ example }] }] }
• feedback { id, time, author, notes [{ gauge, note }], reviews [{ persona { id }, notes [{ gauge, note }], skills [{ id, notes [{ gauge, note }] }] }

Where feedback on skills can then be aggregated in various ways per skill/level/persona/time/globally, but always with additional context of where it came from to help evaluate relevance and value. Not sure that fits in with the current project goals of more rigid spreadsheets/forms.

The reason I originally asked is because I wanted to do a self-assessment with my new manager and was trying to figure out how to review from the existing skills and personas. The lengthy skills.yaml felt intimidating so I ended up splitting them per area and filling them like a YAML engineer (example) before converting it to something more readable (example; via hugo).

I can see the more complex goals, so I don't think the original goal of this issue applies anymore. Feel free to close if there's no more useful discussion about any of this.