mlibrary / heliotrope

Codebase for Fulcrum, a Samvera-based digital publishing platform built by the University of Michigan Library

Home Page:https://fulcrum.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Review draft JIRA board

mbakeryo opened this issue · comments

Review the JIRA project board:

https://tools.lib.umich.edu/jira/secure/RapidBoard.jspa?rapidView=46&view=planning.nodetail

Add your questions/concerns about JIRA features/functionality/workflow stuff to this Google sheet: https://docs.google.com/spreadsheets/d/1KPK6hxg0dLjodrs27A5c-oJuZv6Ea--P2kgVCLW2UyY/edit#gid=0

We'll need to collect feedback to send to Noah and discuss how best to move forward.

Please have your feedback in on the sheet by eod Monday, April 30.

Per our discussion on 4/25/18, what are the things we really need to have in place to migrate?

Work on FF
Make sure we understand how to have CSB on the Heliotrope board
Make sure we can have all tickets (e.g. closed) moved into JIRA

What am I missing?

📣 Publicly viewable issues.

I am going to be annoying about the "public issue thing" and push us to continue considering what we lose if we close issue tracking off to the world, especially in terms of project visibility.

For example, we plan to move from demos to release notes at the end of sprints. Would we not continue to need publicly viewable issues for our Release Notes (see Release Notes 50)? How useful would the release notes be without links to issues if someone (in Samvera-world or a stakeholder) wanted to see more info about an issue that was closed? Our GitHub Releases also link to closed issues. Will we need to put more helpful information there to describe each closed issue if we can't link to a publicly viewable ticket?

Where else are we relying on linking to issues for the public or stakeholders? And what kind of project visibility will be expected for stakeholders? If closed to the public, will stakeholders need JIRA accounts?

If the move to JIRA is to align with LIT and give managers a way to do more sophisticated project metrics, I think that is great. But we certainly shouldn't be moving to JIRA to make our project less visible to Samverians, stakeholders, or the rest of the world.

@jgmorse How would you like to handle the go-forward in regards to our concerns - namely the publicly viewable issues blocker? Do you want me to invite Noah to a standup where we can discuss as a group and get his thoughts?

You can find some notes about the parking lot discussion in our standup notes: https://docs.google.com/spreadsheets/d/1ZwjqBiAMzzOMwkYwhGZ4BJoO33jDNctTpoColVV1DLo/edit#gid=289876209 in MBY's column for May 3, 2018.

Action items:
Jeremy will talk with Charles about what our grant obligations are and his opinion on what to do
Noah will check in with the JIRA team about the visibility issues

We'll come back to this once these items have been done.

We discussed publicly viewable issues today and I'm happy to confirm: this is totally acceptable and appropriate.

The topic of engaging external collaborators needs some more structured discussion -- there are a number of types of feedback (technical vs. usage), mechanisms (SD project, issue collector, email, accounts, GH as inbox), and challenges (tacking, linking, syncing) so mapping out the actual need there is the first step that will guide us.

Per standup on 5/4/18, @jgmorse will work on next steps.

Migrated to JIRA on May 14th