Using the Priority Field for Roadmap tracking

In an effort to make project work more transparent, I was thinking of 
ways I could make it more clear where I would like to go with the 
calendar project.

I was often asked what the roadmap is and I usually started with "Since 
we aren't very many developers, there are no specific deadlines...". I 
have a few things I want to do first, like fix the tests and ical.js 
integration, but I don't know when these will be completed. In 
consequence, tracking bugs by target milestones will only have us moving 
bugs from one to the next.

The devtools team uses the priority field for tracking their bugs. As 
far as I've seen, they use P1, P2 and P3, with these meanings:

P1: very important or blocking others
P2: important
P3: valuable, can wait

I think it would make sense to do something similar for Calendar. 
Devtools has a rule that P1 and P2 bugs MUST have an assignee. I think 
this will be hard for us to manage, we would end up with only P3 bugs. I 
think we should relax this rule so that P1 bugs SHOULD have an attendee, 
and P2/P3 bugs MAY have an attendee. Alternatively we could drop the 
rule altogether.

I don't suggest marking all bugs with P1/P2/P3 at once, its perfectly 
fine to leave bugs without a priority. Instead, I would start marking a 
few bugs P1, then we can go from there.

We could also set up a roadmap page (on the website, or MDN if possible) 
that automatically retrieves the P1/P2/P3 bugs and displays them, 
possibly with a motivational text encouraging developers to help out 
with the P1/P2 bugs if they really want to help, or at least aim for the 
P3 bugs.

What do you think about this? Counterproposals? Slight changes? If no 
one objects in a week or two, I will start marking bugs P1 as mentioned.

Philipp