reosarevok: yeah, I could - but is it really useful to interested users?
I thought it was mostly developer powow?
reosarevok
Well, it's a music technology group after all
Aren't people into digital music stuff?
warp
it's mostly useful for anyknow who knows musicbrainz. if you're not familiar with musicbrainz it will considerably less useful.
still, if you're into any kind of music metadata / ontology / etc... you should be familiar with musicbrainz! :)
alastairp
right
warp
alastairp: certainly not just developers
alastairp
e.g., first item on the agenda is "Moving MB to cloud hosting". Not really ontology related :)
warp
alastairp: that agenda doesn't look final :)
nikki
alastairp: we apparently have a few rooms, so we can split up
so just because some people are being big geeks in one room... :P
warp
alastairp: how should we model series and box sets? genres?
reosarevok
alastairp: since I myself don't care about some of those points, I'd be happy to help other peoples with more user-related concerns in room 2 :p
Guess others would too
Dunno
warp
alastairp: "our stuff is hard for beginners"
reosarevok runs to a violin concert, back later
alastairp
right, sounds reasonable
warp
etc.
alastairp: more than enough non-developer topics on the agenda
CatCat
this jenkins guy sure is very spammy with his links :)
ocharles> 3 months => high priority, 12 months => normal priority, unscheduled => low priority
don't do that
nikki
that's usually good news, it means stuff's being developed :P
CatCat likes it the way it is
what's the point of having it the way it is if the way it is doesn't work?
CatCat
i think that, something might be high priority ,but can do to still wait a 12 months
nikki
that doesn't really make sense to me
CatCat
(for example)
nikki
if it can wait, it's not high priority
CatCat
an addiotn of a red "zomg urgent" button though, might be ok :P
(only awaialbe for bug type tickets)
nikki
we have five priority levels anyway
alastairp
Freso: got it
Freso
\o/
nikki
I don't really mind the exact way the devs want it to work, as long as the people who need to know how it works know how it works and tickets that should be fixed quickly are seen and fixed quickly regardless of who enters it and other tickets are processed in some way that means they get resolved in some way in a reasonable amount of time
Freso
+1
CatCat
yes, fair point
nikki
and ideally we should disable any parts of jira that we're not using and that are disableable, to make it as easy to get right as possible (for example when I was putting "beta" in the summary, the affects version and the fix version because I wasn't sure which was the right place)
CatCat
i forget that people see things differently than me :P
what i mean is "*I* thing tis high priority, but i understand that in the grand scheme of things ,this isn't important to mb as a whole"
nikki
that's what the scheduling stuff is for
CatCat
indeed, os for those i chose 12 months
because i WANT it fixed within the year even though i'd LOVE to have it fixed within 3 months
nikki
the one thing I do like about how it works now is that features get an actual date, so we can tell if things are getting repeatedly put off. I'm not sure if the suggestion is to remove dates entirely or just to remove the buckets but keep the due dates
