| Change History |
|---|
...
Everything is an issue of some description, and ties back to a previous “Initiative”, in Jiraspeak.
Maybe we don’t have documentation of how or why or whose epic, or maybe it was something I did last week that had downstream consequences, but everything we do is attached to something bigger
“Tickets”/ tts-slate e-mail isn’t an area— in Getting-Things-Done parlance, it’s an Inbox—a place where stuff waits to be added to the workstream as a bug or a task or a story that is part of an Epic.
Documentation and client training are part of every issue. There is a bigger Training/Outreach/Knowledge Management “Area” in PARA terms, as well, but every issue also includes both.
Was thinking that we should connect Confluence → Jira but recently realized the big benefit might be pulling Jira into Confluence… Saw some videos where people created pages in Confluence to display high-level info about ongoing projects. 🤯
Jira Issue Types
...
Suggestions for structure
Jira Projects are the top level; for now, Slate is our one and only top level project.
Initiatives are the biggest chunks—these are the PARA areas
Training/Documentation/Outreach
Jira Legacy showSummary false server System JIRA serverId 5443b7f3-2f11-3f32-ba15-42d15098c09a key ST-51 Requested Updates/Development (aka ‘unnecessary updates’)
Necessary Updates/Cycle Prep
Jira Legacy showSummary false server System JIRA serverId 5443b7f3-2f11-3f32-ba15-42d15098c09a key ST-52
Epics, 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/outcome/process an office wants, 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.
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
...