| Change History |
|---|
Assumptions
...
Suggestions for structure
Jira Projects are the top level; for now, Slate is our one and only top level project.
Epics are the bigger chunks—like the basic structure we started here:
...
I have probably been watching too many Confluence videos, but I like the idea of a story as the client desire/what they are getting from this. They may or may not line up exactly with how we know the Epic is complete, but it’s not a hierarchy—“ story” is something parallel with tasks.
I think the PARA Areas for our work includeInitiatives are the biggest chunks—these are the PARA areas
Training/Documentation/Outreach
Requested Updates/Development (I was tempted to label this aka ‘unnecessary updates’)
Necessary Updates/Cycle Prep
I think Areas are Initiatives… especially if we are careful in identifying who our clients are, so we can track how much effort/time each school is gettingEpics, Stories, Bugs, Tasks, and Subtasks are all types of Issues
Epics are the things we typically identify as the ‘things we are working on’; examples include setting up data for Marketing dashboard for NUTR, PTCAS 2024 Cycle prep, Cleanup of Dept App query base
Bugs are the immediate need this-is-broken e-mails or chats; typically this would roll up to a Cycle Prep Initiative (aka ‘something we didn’t update), but there are use cases for broken documentation.
Tasks are the base unit of work, broken down even further into sub-tasks as necessary.
Stories are the least clear. It may be the initial client request, or the thing an office wants to do, but we shall see if this really lives in Jira, or works better in Confluence
There are functional areas in Slate (forms, rules, queries, reports, workflows), which I think are labels in Jira (and in Confluence)
The instance(s) the work is related to also needs to be tracked somehow
Thinking about this team as a global provider of services, perhaps also some way to track how this issue is scalable/relates to other instances/aligns with our goals
For the next two months, it doesn’t seem like we are going to have a lot of time to developing any sort of organized system. I suggest we set ourselves some basic principles, and then work ‘our system’, whatever that looks like, until we can actually spend some time together looking at what works.
As much as I hate it, for Jira that probably means not deactivating a billion fields and cleaning up the views, by letting everything ride (and maybe adding more) to find things that capture the sort of data we want.
I think Confluence will benefit from us just building pages that work for whatever we are documenting, and over time figuring out how all of the pieces fit together.
The one Confluence suggestion I have is that we make Make all the labels for everything we can think of in Confluence, and use them all over everything. By August we can pare them down and figure out what actually makes sense.
Learn more about page structure and how it intersects with macros; that is, thinking about how we organize content within a page to maximize its usefulness/adaptability
using headings and tables of contents
Suggested Resources
https://youtu.be/5p3QzaS33GA This video really helped me “get” Confluence… it’s long but it covers a lot (and I listened at 2x speed).
...