I think this topic came up in the past but it was more of a "wouldn't it be cool if we did this" thing than an actual proposal. While at FUDCon Lawrence, we came up with a proposal to create a web form to assist in proposing blocker and freeze exception bugs in the blocker tracking app.
Current Process
The current process is a bit complicated and I can see how it would be a bit intimidating if you're not already used to it.
- Find the relevant tracker
- Based on Fedora version, milestone, blocker/freeze exception
- Could also memorize the tracker alias naming format
- Assuming that you have the correct bugzilla permissions, change the blocks field on the bug you're proposing to have the correct tracker
- Add a justification or a release criterion which has been violated to a comment in the bug.
This is just the proposal process - there is nothing in there about knowing what is appropriate to be proposed as a blocker or freeze exception.
One of the ways that this manifests is during the review process. During Fedora 18, we saw a lot of bugs that were proposed without any justification or explanation about why the bug would be important to fix or how it qualifies as a blocker. To me, this means that the process needs to be more discoverable and user friendly.
The Proposed Change
I have more things in mind for making the blocker process under control but a lot of that isn't going to happen for F19, if it happens at all (I've yet to propose anything specific). This proposal, while I think it will help, isn't going to magically make the blocker process better - just easier to understand by someone who isn't incredibly familiar with all the details.
The basic idea is to have a web form in the blocker tracking app which allows users to log in with their FAS id, fill out a form and press 'submit' to propose a blocker or freeze exception bug. This provides a level of abstraction which makes it clear what kind of information we're looking for in a proposal and helps with the question of "how do I propose a blocker?".
I'm still working out the details of how the pages would flow but wanted to start communicating early in the process instead of just talking about the finished product.
Initial UI Ideas
After the initial discussion at FUDCon, we worked with Emily Dirsh to come up with a UI sketch for the web form that we'd use for proposing new blockers or freeze exception bugs.
I've made an initial mockup of the page in HTML (nothing is hooked up, the submit button won't do anything) for initial review but I expect the page to change quite a bit as we actually implement the page going forward.
Stuff TODO
There is quite a bit of work that'll need to be done in order to actually make this all work, even just an initial version.
- Associating bugzilla user with FAS users
- Users' FAS emails match bugzilla emails more often than not but it is not at all uncommon for them to not match and this case needs to be handled
- Adding the ability to change bugzilla bugs in an automated way
- This shouldn't be hard in itself but bugzilla doesn't exactly have a reputation for being the fastest thing ever. I'd rather avoid delaying a page load while waiting for bugzilla to respond to change requests.
- Implementing FAS integration
- A lot of the work has already been done in Flask-FAS but it will require integration and testing.
- Figuring out the page flow
- The concept is pretty straight forward but it lacks any handling of stuff like whether the bug is already proposed as a blocker or if there are errors in the form data - basic web development stuff but it does need to be handled
Anyhow, feel free to either comment here or on the Fedora test list if you have suggestions, concerns or are interested in helping. As always, help is appreciated.