Welcome to the team. Getting CVS commit access should not be an issue
after you submit a couple of patches and we go through the process of
finalizing the requirements and documenting them in the Wiki.
I will try to keep my reply short :)
- Introduce Category Id - issues with copy/move issue (are issues
going to lose category when copied or moved to another project)? -
category id in general is useful to Mantis. I did this to versions
but not categories.
- Support for Global Categories - Would be useful. As we work on the
requirements we will understand more the impact on Mantis usability.
I really would like to avoid complicating the categories support. You
may want to look at Global/Private Profiles as a similar feature.
- I was thinking about this feature and talked about to Gianluca (I
think). So I believe it will be very useful.
- Do we really need a Tag info page? How about a multiline bubble
with a short description when user hover on it?
- Rather than having the tag info page show the issues, we should
support filtering by tags. This will give us paging, saved filters,
- Lets use "tag" rather than "keyword" as the terminology.
- Report an issue per feature or even sub-feature. These issues will
be used to track progress, post patches, associate requirements with
the corresponding Wiki page, etc.
- Avoid patches that include more than one category.
- The bigger the feature the more important it is to agree on the
requirements first and document them on a Wiki page, review it on this
mailing list, and then start the coding. This also provides a good
starting point for the documentation of the feature once it's done.
It also avoids half-baked features like "sub-projects".
On 7/24/07, Gianluca Sforna <giallu@...> wrote:
> On 7/24/07, John Reese <jreese@...> wrote:
> > Hello Mantis Developers,
> Hi, and welcome onboard :)
> > I have already submitted a patch to paulr over IRC that enhances the
> > Roadmap and Changelog pages to show parent/child relationships in a
> > nested list,
> Could you please open a bug for this on http://www.mantisbt.org/bugs,
> attaching your patch to it?
> > First, I need to create a cascading project category system, where the
> > Mantis user can create a set of global categories, and categories for
> > each project/subproject. When submitting/updating a bug, the user
> > should be able to select from all the global categories, all categories
> > for the bug's project, as well as all categories in the bug's parent
> > project(s).
> > To reach this goal, I am thinking the best method would be to add a
> > category_id column to the project_category_table, which would be unique
> > for every category. Global categories would have a project_id of 0.
> > Then the bug_table would need to be modified to use the new category_id
> > instead of the category's name. When getting bug information, a simple
> > join on the project_category_table would suffice to get the category's
> > name and grouping (global vs. project). The bug update pages would only
> > allow the bug to select a category_id belonging to a parent project or
> > the global namespace.
> If you are really going to work on this area, be prepared to handle
> the flood of bug reports it triggers: it seems that each and every
> user has a different idea of how the project/subprojects feature
> should behave.
> Personally, I believe the whole concept is flawed and should be
> discouraged (if not removed from the code...)
> > Secondly, I need to create a keyword tagging system for bugs that would
> > allow a user to attach any number of keywords to a given bug, which
> > would either be chosen from a list of all existing keywords, or could be
> > added/created on the fly. When viewing a report, clicking a keyword
> > would then take the user to a page displaying information about the
> > keyword, including lists of bugs associated with it, and the ability to
> > edit the keyword's name or description.
> > For this piece, I was planning to create a keyword_table with
> > keyword_id, name, and description columns, as well as a
> > bug_keyword_table that would link bugs to keywords. Keywords would be
> > able to added/edited from the bug view or update pages, and would have a
> > threshold configuration to prevent non-privileged users from making changes.
> I like this one, the stuff looks mostly the same as what bugzilla
> does (at least judging from a quick glance on their DB schema). Some
> details should be ironed out before the actual implementation, but
> I'll be happy to see this into mantis.
> Please open a new bug report to track this propsal
> > Also, I am greatly interested in joining the Mantis development team to
> > help fix bugs in the project on a regular basis, even outside the scope
> > of my current employment and modifications to Mantis. Would it be
> > possible for me to get CVS access to the project, or should I just
> > continue to generate and patches as I can?
> Any help is appreciated :)
> I think you can start contributing by attaching patches to open bugs
> in the tracker. Those with CVS access (including me) can proxy your
> contributions into trunk. After a few patches will be accepted, I am
> sure you will be granted full commit access to CVS.
> If no-one steps up to review/commit your contributions in a timely
> fashion or you want to discuss implementation details, feel free to
> ask here
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> mantisbt-dev mailing list