prioritizing custom fields development

[Max Kanat-Alexander]

On Wed, 2006-02-22 at 15:24 -0800, Myk Melez wrote:
> My initial custom fields implementation has now been checked in and
> will be appearing in the 2.24 release.  It supports adding plain-text
> custom fields which can be edited from the "edit bug" form and
> searched against from the "search" page.  But the implementation needs
> more work to be truly useful, and since there are many valuable
> enhancements, it would be useful to prioritize them.
> [snip]

	Here's what I was thinking for development order:

	1. Enhance the current functionality to make the field appear on all
the various pages where it's needed: 

	buglist.cgi, query.cgi, “Change Several Bugs at Once”, the “Long List”
format of a bug list, and the “Printable Version” of a bug.

	I think they already appear in the XML, yes? So we don't have to worry
about that.

	2. Make the field optionally appear on enter_bug.cgi.
	3. A web interface for administering existing custom fields.
	4. Type-constrained plain-text fields.

	I put those in the order that I think they'd be most useful to users,
based on the type of fields I've been asked to add to Bugzilla for my
clients.

	Beyond that, off the top of my head I'd say:

	5. "Bugzilla user" fields
	6. "Bug ID" fields
	7. Multi-select fields
	8. Ability to position fields at arbitrary positions.

	Also somewhere in there should be the "change certain existing fields
into instances of the custom field".

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.