For example:
With a Projection, all of the default terms assume something that exists is going to be changed:
Minor Fix, Major Rework, Redesign
But that doesn't apply to new efforts, where the functional equivalent could be:
Small New, Significant New, New Subsystem
In this case, I don't care if a change is a minor fix to existing code or a small new program, but I do want to see all "minor" stuff together when I do a search, and the projection enum would have the same value for Minor_Fix and Small_New.
So, we can add constants and enums with different enums, but is there any harm in adding a new contant or enum with the same value as another?
On the down-side of that practice, what if we actually do want to see just the tickets related to New code and not to existing code? A search for either will always return tickets for both, because the enum values are the same.
Someone could suggest that rather than adding new projection types it might be more appropriate to add a custom selection for New vs Existing code, and then change projections to Minor, Medium, and Significant. Sure, this is just an example.
As another example, what would happen if we added another developer role, that for current purposes is exactly the same as the default?
In this case, a search for anything assigned to APP_DEVELOPERs would return hits for tasks assigned to DATABASE_DEVELOPERs. The only way to separate those out is to have different values. Sure, we can easily add 1 to the values, but then we need to be careful about thresholds. Example:$g_access_levels_enum_string =
'10:viewer,25:reporter,55:database_developer,55:app_developer,60:senior_developer,70:manager,90:administrator';
define( DATABASE_DEVELOPER', 55 );
define( 'APP_DEVELOPER', 55 );
In that scenario, the person modifying this threshold needs to know the value of the constants to ensure all developers are getting notifications ... that kinda defeats the purpose of a constant. That case leads to consideration of extra constants to ensure a "min/max range of developer types for a threshold":define( 'DATABASE_DEVELOPER', 55 );
define( 'APP_DEVELOPER', 56 );
$g_notify_flags['new'] = array(
'threshold_min' => APP_DEVELOPER,
'threshold_max' => DATABASE_DEVELOPER,
);
Is it better to structure like in that last example?define( 'MIN_DEVELOPER', 55 );
define( 'DATABASE_DEVELOPER', 56 );
define( 'APP_DEVELOPER', 57 );
define( 'MAX_DEVELOPER', 59 );
$g_notify_flags['new'] = array(
'threshold_min' => MIN_DEVELOPER,
'threshold_max' => MAX_DEVELOPER,
);
Unless someone can propose a better practice, I might go with that last model. An advantage is that it immediately allows for more refined reporting. A disadvantage (with this specific example) is that anyone who is searching or filtering needs to understand how that works, no longer just searching for "Developer" but App Developer OR Database Developer. It also leaves the UI with these generic "Min/Max Developer" fields which I wouldn't want people to use - and would probably need to remove them with a plugin.
This doesn't just apply to roles or projections. I have to-do items to make changes to other options as well, so I'd like to understand this in a general context.
Thanks.