It’s a wishlist of Open tickets. Wouldn’t necessarily even call this a commitment to a roadmap.
Roadmaps are just wishlists with a committed to priority list, like an assembly line. Programming doesn’t work like an assembly line and anyone trying to convince you to the contrary is bullshiting marketing.
Every task has the potential to bring forwards new information that changes the order in which tasks should be completed, let alone which tasks even need to attempted. You only get all the information once you’ve finished.
Instead of having an inflexible commitment, use a wishlist, and do the tasks in order of which one makes the most sense at the time.
75% of Open tickets will never get resolved anyway.
Well, let me break it down for you since you don’t seem to work in this space:
A Roadmap is a strategic timeline of targeted goals that are estimated to be completed in a specific timeframe that is NOT nebulous. It’s done this way to provide consumers of a product some knowledge of where the product is going to entice them to buy-in to said product to allow them to estimate their own commitments to the project and adoption.
A backlog is NOT a Roadmap. I planned orchestration of tickets is a Roadmap. We create this to ensure users that problems they are experiencing will be resolved, and in what order to expect them to be resolved. This works for both for-profit engineering, and also FOSS projects. A great example of this is the Roadmaps provided by distros uses by Enterprise customers.
Your comment about “inflexible commitment” seems to say you don’t understand the above points. If you’re pushing a product which you want people to adopt, and you’re communicating to them why they should adopt it, the last thing you would want to do is say “Hey, we’re kiiiiinda going this way, but maybe not. We’ll see.”
Programming DOES work like an assembly in a sense. That’s why you have tickets, tags, classification, triage, status, and…backlog. What gets thrown in the floor is what I’m talking about.
Regardless of how you feel about the pace of the project, it’s absurd to throw out a bunch of ideas as tickets and expect them to all get done without a commitment. Or, dare I say, a roadmap.
It’s a wishlist of Open tickets. Wouldn’t necessarily even call this a commitment to a roadmap. 75% of Open tickets will never get resolved anyway.
I don’t understand comments like this
Roadmaps are just wishlists with a committed to priority list, like an assembly line. Programming doesn’t work like an assembly line and anyone trying to convince you to the contrary is
bullshitingmarketing.Every task has the potential to bring forwards new information that changes the order in which tasks should be completed, let alone which tasks even need to attempted. You only get all the information once you’ve finished.
Instead of having an inflexible commitment, use a wishlist, and do the tasks in order of which one makes the most sense at the time.
Based on what?
You can clearly see that practically all tickets in their previous epoch were resolved: https://github.com/orgs/pop-os/projects/23/insights?period=max
Well, let me break it down for you since you don’t seem to work in this space:
A Roadmap is a strategic timeline of targeted goals that are estimated to be completed in a specific timeframe that is NOT nebulous. It’s done this way to provide consumers of a product some knowledge of where the product is going to entice them to buy-in to said product to allow them to estimate their own commitments to the project and adoption.
A backlog is NOT a Roadmap. I planned orchestration of tickets is a Roadmap. We create this to ensure users that problems they are experiencing will be resolved, and in what order to expect them to be resolved. This works for both for-profit engineering, and also FOSS projects. A great example of this is the Roadmaps provided by distros uses by Enterprise customers.
Your comment about “inflexible commitment” seems to say you don’t understand the above points. If you’re pushing a product which you want people to adopt, and you’re communicating to them why they should adopt it, the last thing you would want to do is say “Hey, we’re kiiiiinda going this way, but maybe not. We’ll see.”
Programming DOES work like an assembly in a sense. That’s why you have tickets, tags, classification, triage, status, and…backlog. What gets thrown in the floor is what I’m talking about.
Regardless of how you feel about the pace of the project, it’s absurd to throw out a bunch of ideas as tickets and expect them to all get done without a commitment. Or, dare I say, a roadmap.
This is the kind of divorced from reality slop I expect to see from managers who think that 9 mothers can birth a child in one month
Probably depends on the species. You did not specify human, so we have to assume its alien.
Mkay. So you’re just some person out here on the Internet who has zero concept of how this works as well I’m assuming?
Feel free to dispute any single point I’ve made.