Implementing a UI for bugspad.
An overview of your proposal
Bugspad is a redoing of bugzilla, with modern technologies, keeping in mind speed and performance as the key metric for optimisation. It is aimed to provide a smoother and user friendly experience with the bug tracking/solving experience.
The need you believe it fulfills
The current bug tracking famous bug tracking system, Bugzilla is quite good however it misses a lot, on performance,speed and some very key basic elements like openid login, user profiling to rate users. It is performance centric, and adds in some handy features, to make the experience of bug solving a pleasant one. Hence it is required to redo bugzilla with modern technologies.
Any relevant experience you have
I have used bugzilla, for over 2 years now, and am well versed with the working of a bug-tracking system and the features it currently lacks in terms of performance and speed. I also possess the required coding skills for this project.
How you intend to implement your proposal
The main job would be to implement the UI, the backend is almost complete and working. I am planning to use flask as the web framework for building the UI. Redis would be used as cache storing, to speed up retrieval.
Currently the backend has models created for bugs, users, and their activities such as commenting, filing a bug etc. All that is required to map these to a smooth working frontend system, keeping in mind performance and intuitiveness.
Landing page would have four buttons, FileBug, SearchBug, NewAccount, Log in with OpenID/FAS. Currently bugzilla does not have any "login with .." features whatsoever. So I am planning to add this to avoid the pain of going through the manual registration process all over again. We can use flask-openID to achieve this. Apart from the basic information, like email and password the user profile would also be having fields such as default hardware, default os etc. which the user can set, and need not have to unnecessarily fill in everytime he/she files a new bug.
File a new bug page, would try to ascertain maximum information, such as default hardware, default OS, through user profile, and simple q/a. The overall q/a process would be made intuitive with the key theme of how to reproduce the bug, so that user is not bored filing and at the same time, gives complete info. to the one solving the bug, in reader friendly format.
Searching bugs page, this would allow user to search for the bugs categorically, and quickly. Using db query on the flask models would be sufficient. Also, sorting by time, by difficulty, alphabetically etc. would be done client side, and would remain same more or less.
The Bug description page, this will contain the bug ID, and simple steps to reproduce the bug in the header, with no mention of "Reported by" and "Assigned to" etc. The less relevant information would be displayed below the comments on the bug. There would be support to comment from your mail itself, as is with bugzilla.
The admin interface, to implement the admin interface, we would be using the flask-admin and user authorization system.
Exposing an API for bugspad. This needs to be done so that bugspad can be easily used by people suiting their particular needs, hence it needs exhaustive and complete documentation. Also, this API would be the supporting backend for our flask frontend.
A rough timeline for your progress
:Community Bonding Period:----------
21 April - 24 April : I am going to re-discuss my implementation plans with my mentor, incorporating in the suggestions received, and clarifying the design issues (if any).
25 April - 28 April : Go through the backend code, develop few sample flask apps, integrating it with backend.
29 April - May 05 : Discussing with the Fedora infra team, about the use of flask-admin for the admin interface. Also learn about the Fedora project and different subprojects inside it.
May 06 - May 14 : Research on the performance issues of bugspad. Form a draft work plan.
May 15 - May 18 : Re-discuss with the Fedora infra team about the feasibility of the work scheme, and incorporate changes suggested if any.
:Coding Period Begins:-------------
May 19 - May 23 : Create bug, listing of bugs and view details and changing to bug should work in first round of development.
May 24 - May 30 : Improve the UI made in last week. Make sure everything works as expected by upstream in those areas.
May 31 - June 6 : Basic user login with Openid will work in this time frame. We should also have a dev instance ready by this time.
June 7 - June 13 : Basic level of admin interface should be ready
June 14 - June 20 : 2nd round of admin interface work.
June 21 - June 27 : 1st round of search interface should be ready. We should also be self hosted by this time.
Mid term deliverables
Basic working UI for bugspad, with searching, filing bugs.
July 1 - July 4 : 2nd round of search interface. Primary focus will be performance.
July 5 - July 11 : Going though jira and Bugzilla once again for missing features and discussions with upstream.
July 12 - July 30 : Creating all decided features from upstream, and rigourously test them.
July 31 - August 8 : Helping the mentors with rpm packaging of the frontend.
August 9 - August 21 : Backup time for delays due to unforeseen circumstances.
End term deliverables
A basic fast and efficient bug tracking system with UI in flask.
Any other details you feel we should consider
Have you communicated with a potential mentor? If so, who?
I have talked to the mentor Kushal, discussing the real motive of the project, and also on the technologies which we would be using.