Any System Is Only As Good As It Is Used

There is a fine balance between meeting robust needs, managing those needs with current resources, and being effective in the end.  A good litmus test for any system is to ask yourself if it is helping or hindering the area of work and benefit for which it is targeting.  If a system is in place just to be fed, then chances are it is not an effective booster for those using it. However, if it helps with organization and increases overall productivity and/or quality, then it is a keeper.

GitHub is a great platform for source code management and within the platform, there is great flexibility on how it is used.  Individuals and teams can cater usage to their specific needs, within functional limits of course. In the area of issue management, there are several GitHub features available within repositories.  

One of these is the Projects feature.  Projects can be created and used for Kanban-style boards.  Cards (notes, issues and/or pull requests) are added and moved in an automated or manual fashion to various columns within the project board.  These columns can represent anything that meets the needs of those using it (e.g., status, phase, steps, actions).

Another is the Labels feature.  Labels can be created and associated with issues and/or pull requests.  The usage of these are up to those using them. The online limitation is the length of a label, which is 50 characters. 

Since DNN moved source code to GitHub from CodePlex, our issue management has been fairly rogue and based largely on individual preferences over the years.  We have loosely used a list of non-systematic Labels, most of which meant something to someone at some point along the way.  However, we have never implemented a strategic label system and associated processes for using that system.  What we have in place now is certainly better than using no labels at all, but we can be more strategic moving forward.  Therefore, the Leadership Team is establishing a clear process and system for Issue Management, which includes the processing of pull requests.
 

Old Label "System"

Below is a screenshot of the old labels implemented on the Dnn.Platform repository on GitHub.  Some of these were default labels added by GitHub to any new repository.  Others were created over the years for various usage.

New Label System 

After researching quite a few other large open-source GitHub projects, a nice trend surfaced of using prefixes for Labels.  This, along with a clear process for issue management, could be extremely beneficial to our project.
 

Label Prefixes

• Status:

• Type:

• Priority:

• Effort:

• Alert:

• Area:
   

Status

This prefix depicts the status of an issue in the workflow.  An issue should always have one, but only one, Status label at any given point in time.   The following labels have been implemented with this prefix.

• Status: New

• Status: Ready for Development

• Status: On Hold

• Status: Development

• Status: Review

• Status: Testing

• Status: Blocked

• Status: Closed

Note:  The “Status: New” label is auto-applied to all new issues created.  This is possible via front matter in the issue templates.
 

Type

This prefix depicts the type of issue.  An issue should have no more than one Type label at any given point in time.  The following labels have been implemented with this prefix.

• Type: Bug

• Type: Enhancement

• Type: Feature

• Type: Build/Release

• Type: Maintenance

• Type: Documentation
   

Priority

This prefix depicts the priority of an issue.  An issue should have no more than one Priority label at any given point in time.  The following labels have been implemented with this prefix.

• Priority: Low

• Priority: Medium

• Priority: High
   

Effort

This prefix depicts the estimated level of effort required for issue resolution.  An issue should have no more than one Effort label at any given point in time. The following labels have been implemented with this prefix.

• Effort: Low

• Effort: Medium

• Effort: High
   

Alert

This prefix depicts alerts used to draw attention to issues given special consideration.  An issue can have one or more Alert labels at any given point in time. The following labels have been implemented with this prefix.

• Alert: Breaking Change

• Alert: Noteworthy

• Alert: Pinned
   

Area

This prefix depicts the issue’s related area within the codebase.  An issue can have one or more Area labels at any given point in time.  The following labels have been implemented with this prefix.

• Area: AE > Dnn.React.Common

• Area: AE > Dnn.EditBar.Library

• Area: AE > Dnn.EditBar.UI

• Area: AE > Dnn.PersonaBar.Extensions

• Area: AE > PersonaBar Ext > AdminLogs.Web

• Area: AE > PersonaBar Ext > Extensions.Web

• Area: AE > PersonaBar Ext > Licensing.Web

• Area: AE > PersonaBar Ext > Pages.Web

• Area: AE > PersonaBar Ext > Prompt.Web

• Area: AE > PersonaBar Ext > Roles.Web

• Area: AE > PersonaBar Ext > Security.Web

• Area: AE > PersonaBar Ext > SEO.Web

• Area: AE > PersonaBar Ext > Servers.Web

• Area: AE > PersonaBar Ext > SiteImportExport.Web

• Area: AE > PersonaBar Ext > SiteSettings.Web

• Area: AE > PersonaBar Ext > Sites.Web

• Area: AE > PersonaBar Ext > TaskScheduler.Web

• Area: AE > PersonaBar Ext > Themes.Web

• Area: AE > PersonaBar Ext > Users.Web

• Area: AE > PersonaBar Ext > Vocabularies.Web

• Area: AE > Dnn.PersonaBar.Library

• Area: AE > Dnn.PersonaBar.UI

• Area: AE > Dnn.PersonaBar.Pages.Tests

• Area: AE > Dnn.PersonaBar.Security.Tests

• Area: AE > Dnn.PersonaBar.Users.Tests

• Area: Platform > Admin Modules

• Area: Platform > Components

• Area: Platform > Connectors

• Area: Platform > Controls

• Area: Platform > Dnn.AuthServices.Jwt

• Area: Platform > DotNetNuke.Abstractions

• Area: Platform > DotNetNuke.DependencyInjection

• Area: Platform > DotNetNuke.Instrumentation

• Area: Platform > DotNetNuke.Log4net

• Area: Platform > DotNetNuke.ModulePipeline

• Area: Platform > DotNetNuke.Web.Client

• Area: Platform > DotNetNuke.Web.Deprecated

• Area: Platform > DotNetNuke.Web.Mvc

• Area: Platform > DotNetNuke.Web.Razor

• Area: Platform > DotNetNuke.Web

• Area: Platform > DotNetNuke.WebUtility

• Area: Platform > DotNetNuke.Website.Deprecated

• Area: Platform > HttpModules

• Area: Platform > JavaScript Libraries

• Area: Platform > Library

• Area: Platform > Modules

• Area: Platform > Providers

• Area: Platform > Skins

• Area: Platform > Syndication

• Area: Platform > Tests

• Area: Platform > Website

• Area: Localization
   

Label Color Strategy

A color palette strategy has been created for all labels.  The current thinking is to use one color per prefix, but other ideas are being considered as well.
 

Old Projects "System"

Prior to now, this GitHub feature has not been used, other than for testing purposes.  Any old Projects have been archived.
 

New Projects System

This feature, in practice, can add a great deal of unnecessary overhead.  Therefore, at this time we will utilize this feature for Issue Triage only.  The sole purpose will be to review new issues, assign the appropriate initial prefixed labels, and move to the applicable project board column based on the type of issue.

The Issue Triage project has the following board columns:

• Awaiting Triage

• Awaiting Compliance/Verification

• Bugs

• Enhancements

• Features

• Closed

Bold columns are managed via automation.

We currently have two issue templates:

• Bug Report

• Enhancement Request

With a minor modification to these two issue templates, we have the “Status: New” label automatically applied to every issue.  We are researching options for having every issue automatically added to the Awaiting Triage column on the Issue Triage project board.

The triage team, which is currently limited due to permissions issues within the legacy dnnsoftware GitHub organization account, processes each issue on the Awaiting Triage project board column in the following manner.

1. Has CONTRIBUTING criteria been met?

   1. YES - proceed.

   2. NO - at discretion change the Status label to:

      1. “Status: Blocked” and request the necessary changes for compliance

      2. “Status: Closed” and close the issue.

2. Assign the appropriate Type label.

3. Assign the appropriate Area label.

4. Assign the appropriate Priority label.

5. Assign the appropriate Effort label.

6. Change the Status label as appropriate.

7. Move the issue to the “Bugs”, “Enhancements”, or “Feature” column on the project board based on the set Type label.

For those on the triage team with lower technical knowledge, collaboration with more experienced team members are necessary to apply some of the above labels. 

Any issue closed manually, or automatically via a reference on a merged pull request, will be automatically moved to the Closed project board column. 
 

Additional Notes

For now, all other issue types (Feature, Build/Release, Maintenance, and Documentation) would be managed as appropriate by the approvers team.  

A new system for onboarding new ideas for DNN Platform (e.g., new features, significant changes to UI/UX, etc.). This system is called DNN Ideas and we'll be talking about this more in the future.  Once the DNN Ideas solution is in place, Feature issues could be created by the one(s) managing ideas that are ready for development.  

Feature issues could also be created by Mitch Sellers or other designated members of the Technology team.  

Build/Release issues are created and managed by Daniel Valadas.

Maintenance and Documentation issues are created by the appropriate members of the approvers team.

There is more to document as it relates to the management of Status labels for issues throughout the workflow and the assignment of developers to issues, but this should get us moving in the right direction.
 

Closing Remarks

This is a great first step towards a more strategic implementation for DNN Platform Issue Management.  We still have a lot of room for improvement and I am excited about the initiatives underway. Here are just a few to give you additional insight and to impart a sense of trust in our DNN Community and the management of the DNN Platform open source project. 

• More effective GitHub automation

• A system for ideation and funneling of innovative new solutions for the core offering

• Optimized processes for effective issue creation, developer assignment, and work item tracking

The DNN Platform open source project is growing, improving, evolving and become much more strategic.  The more strategic and efficient we are in our operations, the more effective, purposeful and focused we will become.  The more focused we become, the greater the overall positive impact will be!

Get involved…
Find your place...
Be a part of the positive impact!