Better Organizing a Scope & Roadmap #161

New Issue

adam · 2025-12-29T15:35:36+01:00

adam commented

2025-12-29 15:35:36 +01:00

Originally created by @ryanmerolle on GitHub (Jul 6, 2016).

Hopefully I articulated this clearly. I wrote this all up quickly given my discussions with some of the various contributors on irc. This is meant to be a discussion and not my mandate.

I have seen a lot of feedback and feature requests from the community at large. I think this is starting to become a very exciting project for not just network engineers or infra engineers, but potentially even for infra engineers that delve into the areas of application support. With all these users, contributers, and viewpoints the project is getting some helpful feedback, but with the current project organization I see a few risks:

Scope creep
Diverging focus of contributors (potential for development or db approaches that may conflict with one another)
Gaps in functionality or inconsistencies within the application workflows or displaying data models

Ultimately, I think we need to approach the roadmap to allow quick mapping of short term goals and feature requests to long term goals and project development phases.

First, In order to keep the project on task, I suggest we expand the current high level project scope / description beyond:

IP address management (IPAM) and data center infrastructure management (DCIM) tool.

Next, I would suggest we define the roadmap to outline project goals (to be possibly later divided into release numbers). We could use the content in the README.MD to build the current MVP (minimum viable product) feature set. These features would include not just stated functions but also the documentation of said functions.

Optionally, we could take each mapped out goal / focus and map out general phases or x.o releases. Accordingly, as the roadmap pushed out into the future, high level goals and supporting functionality would obviously be less detailed until we made progress on the more near term roadmap.

Lastly, @jeremystretch and team could drop individual feature requests to each of these phases in the roadmap based on said feature aligning to one of the defined goals/phases in the near or long term.

Thoughts? Again sorry for the novel.

Originally created by @ryanmerolle on GitHub (Jul 6, 2016). Hopefully I articulated this clearly. I wrote this all up quickly given my discussions with some of the various contributors on irc. This is meant to be a discussion and not my mandate. I have seen a lot of feedback and feature requests from the community at large. I think this is starting to become a very exciting project for not just network engineers or infra engineers, but potentially even for infra engineers that delve into the areas of application support. With all these users, contributers, and viewpoints the project is getting some helpful feedback, but with the current project organization I see a few risks: - Scope creep - Diverging focus of contributors (potential for development or db approaches that may conflict with one another) - Gaps in functionality or inconsistencies within the application workflows or displaying data models Ultimately, I think we need to approach the roadmap to allow quick mapping of short term goals and feature requests to long term goals and project development phases. **First**, In order to keep the project on task, I suggest we expand the current high level project scope / description beyond: > IP address management (IPAM) and data center infrastructure management (DCIM) tool. **Next,** I would suggest we define the roadmap to outline project goals (to be possibly later divided into release numbers). We could use the content in the [README.MD](https://github.com/digitalocean/netbox/blob/master/README.md) to build the current MVP (minimum viable product) feature set. These features would include not just stated functions but also the documentation of said functions. **Optionally**, we could take each mapped out goal / focus and map out general phases or x.o releases. Accordingly, as the roadmap pushed out into the future, high level goals and supporting functionality would obviously be less detailed until we made progress on the more near term roadmap. **Lastly,** @jeremystretch and team could drop individual feature requests to each of these phases in the roadmap based on said feature aligning to one of the defined goals/phases in the near or long term. Thoughts? Again sorry for the novel.

adam closed this issue

2025-12-29 15:35:36 +01:00

adam commented

2025-12-29 15:35:36 +01:00

@ryanmerolle commented on GitHub (Jul 6, 2016):

Helpful references:

10 Tips to Creating Agile Product Roadmaps
7 Best Practices for Product Roadmaps - Good resource, somewhat contradicts how I mapped out above, but there are several ways to attack this.

@ryanmerolle commented on GitHub (Jul 6, 2016): Helpful references: - [10 Tips to Creating Agile Product Roadmaps](http://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/) - [7 Best Practices for Product Roadmaps](https://age-of-product.com/7-best-practices-on-how-to-build-a-product-roadmap/) - Good resource, somewhat contradicts how I mapped out above, but there are several ways to attack this.

adam commented

2025-12-29 15:35:37 +01:00

@peelman commented on GitHub (Jul 7, 2016):

With regards to First, DCIM is a wonderful buzzword, but unfortunately not one that many people agree upon the definition of. It is typically used to amalgamate several related disciplines surrounding data center management, but what those disciplines are varies depending on the person being queried.

The Wikipedia Article on it is the closest thing to comprehensive I've seen, and lists the following:

Asset Management
Energy Management
Environment Management
Power Management
Change Management
Capacity Management

Change Management (also know as Blame Management), which is an important facet, and one NetBox might consider down the road, but probably not a near-term deliverable.

Right now, in terms of that list, NetBox only very loosely does Asset Management. So while in the literal sense, Infrastructure management might be accurate, the loose meaning of it might cause some grief going forward in terms of the scope of the project.

I think Asset Management is a big facet a lot of IT groups are missing (I have addressed this myself, repeatedly, to the point of frustration at times), and one that makes a large amount of sense given the current trajectory of the project. But it goes well beyond the network, into the realm of tracking assignments, costs, purchase records (usually invoice numbers, packing slips, etc), warranties and support agreements, parts inventories, software licensing, and possibly even SSL certificate documentation (or creation, because once you have the ability to record and verify them, the work to get a self-signed CA and generate your own certs is pretty trivial with a good library).

So yeah...redefining the scope might be a priority :)

@peelman commented on GitHub (Jul 7, 2016): With regards to **First**, DCIM is a wonderful buzzword, but unfortunately not one that many people agree upon the definition of. It is typically used to amalgamate several related disciplines surrounding data center management, but what those disciplines are varies depending on the person being queried. The [Wikipedia Article](https://en.wikipedia.org/wiki/Data_center_infrastructure_management) on it is the closest thing to comprehensive I've seen, and lists the following: - Asset Management - Energy Management - Environment Management - Power Management - Change Management - Capacity Management Change Management (also know as Blame Management), which is an important facet, and one NetBox might consider down the road, but probably not a near-term deliverable. Right now, in terms of that list, NetBox only very loosely does Asset Management. So while in the literal sense, Infrastructure management might be accurate, the loose meaning of it might cause some grief going forward in terms of the scope of the project. I think Asset Management is a big facet a lot of IT groups are missing (I have addressed this myself, repeatedly, to the point of frustration at times), and one that makes a large amount of sense given the current trajectory of the project. But it goes well beyond the network, into the realm of tracking assignments, costs, purchase records (usually invoice numbers, packing slips, etc), warranties and support agreements, parts inventories, software licensing, and possibly even SSL certificate documentation (or creation, because once you have the ability to record and verify them, the work to get a self-signed CA and generate your own certs is pretty trivial with a good library). So yeah...redefining the scope might be a priority :)

adam commented

2025-12-29 15:35:37 +01:00

@jeremystretch commented on GitHub (Jul 9, 2016):

I took a shot at better defining the scope in the "What is NetBox?" section of the introductory documentation.

@jeremystretch commented on GitHub (Jul 9, 2016): I took a shot at better defining the scope in the "[What is NetBox?](https://github.com/digitalocean/netbox/blob/develop/docs/index.md)" section of the introductory documentation.

adam commented

2025-12-29 15:35:37 +01:00

@jeremystretch commented on GitHub (Jul 22, 2016):

In an effort to clean up the issues backlog, I'm closing all issues labelled as "discussion." If there is interest in continuing this topic, please start a thread on the NetBox subreddit. Thanks!

@jeremystretch commented on GitHub (Jul 22, 2016): In an effort to clean up the issues backlog, I'm closing all issues labelled as "discussion." If there is interest in continuing this topic, please start a thread on the [NetBox subreddit](https://www.reddit.com/r/netbox). Thanks!

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#161