Use Case: Distributed Bug Tracking
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Zim |
Confirmed
|
Wishlist
|
Unassigned | ||
Bug Description
A use case for Zim is a wiki and issue tracker for distributed project development.
Description:
* A project directory is setup with a subdirectory for zim
/project
/code
* The project is put under revisions control using Mercurial (could be another DVCS)
* The zim wiki is created in /zim-for-
* the task plugin is enabled
* Zim manually initialized
* an issues page is generated
* a template page for new issues is added
* Workflow for issues
* When a new issue is added the following steps are followed:
* A new item is added to a checkbox list on the issues page. The new item consists of a link to a new page which is located under the issues page. The link contains a uuid to ensure that merged issue lists have unique issues.Tags are added to the description to categorize the issue. For example a new bug is entered as:
[ ] [[+1ff8c260-
* To enter details on the bug, a template page is opened and copied into the text buffer. The link is then selected. The template is pasted into the new page and details are filled in.
* When closing an issue, the the version id for change is added to the page so the change that closed an issue is tracked. In Mercurial, this is done by copying the hash for the changeset, then adding it to the details page for the issue.
* During development, notes are added to the issue page.
* When closed, the check box is selected.
* Changes to Zim are committed with the project. This allows:
* page revisions, changes, change owners are tracked via the DVCS
* issues which are part of a branch are tracked with the branch. If the branch is abandoned, all of the changes are
Features requests that would be useful to improve the workflow:
* ability to sort a list of checkboxes so that as issues are closed, they can be moved down to the bottom of the list
* ability to interpret a page as a form when opened by a link, ability to default to a template if a link is opened on an empty page
* Possible workflow: if a page has a tag (?? @isaform), then when opened via a link, it will present a form which is defined by the contents of the page or a default template. For example
top level page is 'Issues'
a sub-page is '__template__'
the contents of '__template__' is
If a new relative link is added to the 'Issues' page, then if the link is selected, the template will be added to the page and a form will be opened with a field associated with each item.
* Figure out how access Zim from Hg Workbench so the bug tracking can be used directly (See bug-everywhere and BEurtle). I have no ideal how to do this, but it would really be useful!
| Jaap Karssenberg (jaap.karssenberg) wrote Re: [Bug 1183890] [NEW] Use Case: Distributed Bug Tracking | #1 |
| Changed in zim: | |
| status: | New → Confirmed |
| importance: | Undecided → Wishlist |
| Robert (pv-ubuntuone) wrote | #2 |
Sounds like an interesting idea. I think you can make most functionality
already as a plugin without to much work.
The plugin could add 2 toolbar buttons, one for opening a new issue and one
for closing an issue.
The open button would create the new id and fill the template.
The close button would update the page and flag it as closed.
I would not recommend using a page with checkboxes to track the overview.
Rather I would add a custom dialog that gives the overview of all bugs, so
like the tasklist but with slightly different fields and filter options.
Regards,
Jaap
On Fri, May 24, 2013 at 6:36 PM, edtate <email address hidden> wrote:
> Public bug reported:
>
> A use case for Zim is a wiki and issue tracker for distributed project
> development.
>
> Description:
> * A project directory is setup with a subdirectory for zim
> /project
> /zim-for-
> /code
> /everything-
> * The project is put under revisions control using Mercurial (could be
> another DVCS)
> * The zim wiki is created in /zim-for-
> * the task plugin is enabled
> * Zim manually initialized
> * an issues page is generated
> * a template page for new issues is added
>
> * Workflow for issues
> * When a new issue is added the following steps are followed:
> * A new item is added to a checkbox list on the issues page. The
> new item consists of a link to a new page which is located under the issues
> page. The link contains a uuid to ensure that merged issue lists have
> unique issues.Tags are added to the description to categorize the issue.
> For example a new bug is entered as:
>
> [ ] [[+1ff8c260-
> work with last element]] @bug
>
> * To enter details on the bug, a template page is opened and
> copied into the text buffer. The link is then selected. The template is
> pasted into the new page and details are filled in.
>
> * When closing an issue, the the version id for change is added to
> the page so the change that closed an issue is tracked. In Mercurial,
> this is done by copying the hash for the changeset, then adding it to
> the details page for the issue.
>
> * During development, notes are added to the issue page.
> * When closed, the check box is selected.
> * Changes to Zim are committed with the project. This allows:
> * page revisions, changes, change owners are tracked via the
> DVCS
> * issues which are part of a branch are tracked with the
> branch. If the branch is abandoned, all of the changes are
>
>
> Features requests that would be useful to improve the workflow:
> * ability to sort a list of checkboxes so that as issues are closed, they
> can be moved down to the bottom of the list
> * ability to interpret a page as a form when opened by a link, ability to
> default to a template if a link is opened on an empty page
> * Possible workflow: if a page has a tag (?? @isaform), then when
> opened via a link, it will present a form which is defined by the contents
> of the page or a default templat...