Feature Request: Manage Feature Requests

Ray - Webmaster
Ray - Webmaster

The more and more I think about it… the more I think that features in and of themsleves should be a part of plugins that are autonomious in and of themselves. They can use some of the same things other things use, but should ‘make them’ if they are not there, and ‘use them’ if they are.

Like I need to manage feature requests and bug reports and support tickets and all sorts of things like that… things that are related to various things and support the relationships ‘changing’ and maintaing linkages. Like for example, a bug being reclassified as a feature request, or a feature request being reclasified as a bug.

Like a ‘group’ issue being reclassified as an individual issue, and the same in reverse.

Then even linking things like an eratta or a change long, or even a FAQ that are related. I know, I go relationship crazy.

Anyway… some of the fields and relationships for Feature Requests:

status – requested, researching or investigating, developing, on hold for dependency (and then the dependency)

Work record, or activity log, like a status change – and the reason for it. Development update or report on a realease of some kind and the work that went into that release.

Then of course doing notifications for anyone who wants to ‘keep up’ on this particular thing… perhaps the author and others who are anxiously anticipating.

The whole thing kinda needs to be drawn out in a ‘modular’ way. Some screens drawn out and then turned into views and pages pulling in all the related information. I think toolset is the thing I am going to use for this. (I’m secretly entertaining the idea of looking at some of the other solutions out there… or at least some comparisons. I don’t know if I want to spend a bunch of time with all of them trying to do the same things… but it could be a good content series.)



Run Toward the Light!

Invitations are Valueable

Get Yours

Subscription Form
Boom - Test Form 1