Difference between revisions of "GSoC 2014/task-browser-info"

From OpenHatch wiki
Jump to navigation Jump to search
imported>Shauna
imported>Shauna
Line 3: Line 3:
   
 
== Backend ==
 
== Backend ==
 
==== Entering Projects ====
 
   
 
Each bug will be associated with a project. The project itself will have some info associated with it (see the bottom of [http://campus.openhatch.org/projects.html this page] for a portion of that info - links to help info, etc). Ideally this info only has to be entered once, and when entering a bug for a pre-existing project you can just associate it with a project.
 
Each bug will be associated with a project. The project itself will have some info associated with it (see the bottom of [http://campus.openhatch.org/projects.html this page] for a portion of that info - links to help info, etc). Ideally this info only has to be entered once, and when entering a bug for a pre-existing project you can just associate it with a project.
Line 16: Line 14:
 
== Frontend ==
 
== Frontend ==
   
  +
People in the workshop should be able to search or filter through the bugs to find ones matching their skills and interests. They should be able to search/filter along multiple axes (for instance, looking for education projects coded in Python).
How people in the workshops would use it.
 
  +
  +
Ideally people using the browser would be able to add notes to it, though perhaps not edit the main info. It would be neat if there was a field where they could indicate that they were working on it. Perhaps if they removed their name from working on it, they could be prompted as to why they were ceasing work and that information could be stored, either on the bug or hidden for mentors to view.

Revision as of 04:04, 19 March 2014

Workflow

Backend

Each bug will be associated with a project. The project itself will have some info associated with it (see the bottom of this page for a portion of that info - links to help info, etc). Ideally this info only has to be entered once, and when entering a bug for a pre-existing project you can just associate it with a project.

When entering bugs, there should be a number of fields, including: link to the bug, status of the bug, when the status was last verified (default to when the bug is entered), skills associated with fixing the bug, mentor at the event you can ask for help with the bug.

Entering the bugs should be a process that does not require significant work or special permissions for the person entering the info.

We will want the ability to edit and remove bugs.

Frontend

People in the workshop should be able to search or filter through the bugs to find ones matching their skills and interests. They should be able to search/filter along multiple axes (for instance, looking for education projects coded in Python).

Ideally people using the browser would be able to add notes to it, though perhaps not edit the main info. It would be neat if there was a field where they could indicate that they were working on it. Perhaps if they removed their name from working on it, they could be prompted as to why they were ceasing work and that information could be stored, either on the bug or hidden for mentors to view.