Proposal to remove module roadmap images

[julianeisel]

Hi all,

Currently all modules have a roadmap image in the project description on developer.blender.org. For example, here’s the one from the UI module:

I’d suggest removing them (in favor of the proposal below) for the following reasons:

• Purpose of the short, 3 month release cycle was to make work more project target, less release target focused. Project targets should be merged once ready, not rushed to make a “deadline” (even if a rather soft one). There’s always the next release wagon around the corner.
  Asking modules to create pictures with release targets does exactly the opposite of that.
• The images give minimal info. It’s not clear where to get further information, there are no explanations given. You end up making compromises on the content for a visually appealing(-ish) result.
• We haven’t done a good job at updating them regularly. No module updated theirs after the 2.91 release, about half of them weren’t updated since before 2.90.
  Sure, maybe some butts should be kicked, but apparently modules don’t find this important or useful enough to pay attention to it.
• Having to update the SVG is a bit of a hassle. It’s not a big deal, but something that takes some effort to do, while it doesn’t feel like having a clear benefit to the module, will always tend to get lost in the existing mountains of things to be done.

---

Proposal

Make the roadmap project target based (not release target). A simple list of project names with a link goes a long way. E.g.:

There could be a status indication too (e.g. how close it’s to being shipped). But the project description should mention that anyway:

Think this solves all mentioned issues just fine.

[megalomaniak]

Oh god yes please, those pseudo timelines are kinda confusing to users too.

[LazyDodo]

My biggest issue with the roadmaps always has been, they are very terse 2.92 -brushes I’m not overly involved with this module, so I have no idea what it means, and I can’t click on it to get more information cause it’s essentially a jpeg.

Anything that improves that situation is a win in my book.

personally i think i well organized work board for a module can convey this exact same information better than the image can.

[julianeisel]

One thing I want to add…

Since the roadmap images were introduced, I think the principle of autonomous modules started being taken more seriously. So ultimately, it should be up to the module how they present their roadmap I suppose. OTOH it’s nice if all modules do this the same way, avoids confusion too.

So I would like this to be perceived as suggestion to modules, not as something we should dictate. If a module thinks something else will work better, they deserve the benefit of doubt. And if they turn out to be right, other modules can learn from that.

[julianeisel]

@LazyDodo

personally i think i well organized work board for a module can convey this exact same information better than the image can.

For big modules like the UI one, I don’t think this would work. The workboard is quite useful for some things, e.g. we use it extensively for release planning. The first column on the workoard is the one for the next release, and should contain all tasks to do for it (including patches to be reviewed, bugs to be fixed, documentation to be written, …).

But there are hundreds of tasks (think >600 by now) on the UI workboard. We simply can’t organize those well without lots of effort. So sure, parts of it are a mess, but I take that over sweeping issues and tasks under the rug anytime. Generally I think the workboards work better for daily/operational work.
What we could do more often is create (sub-)projects with dedicated workboards, which aligns well with the BI plans to have inter-module squads work on projects.

[1D_Inc]

Yes, updating static SVG pictures can be very annoying (this format is better for reviewing the work done than for the planning process).
It’s probably better to do this kind of thing with JavaScript than regret having to constantly update it.
Indeed, the best option would be to replace it with regular links - they look less modern but are nice to maintain.

[JuanGea]

I understand all the points exposed here and I kind of agree with you.

But at the same time I think there is one important point missing, efficient and clear communication with users.

One of the most important things those Roadmaps achieved is to provide an efficient way of “knowing” what’s happening, and what will happen in the near future in an attractive way.

I agree with the fact that being release driven is not good at all, and being feature driven is way better, however in the proposal there is no clear way of communicating where Blender goes, and in fact it will depend on the opinion of each module owner, so some modules can have a very good communication and others can be completely in the dark, it’s happening right now for some modules, so if that tiny part (that it’s of course outdated) is removed, then it will be a big hit to the communication.

While developers in general don’t like to communicate things, in this project that’s a big part, many of the donations being received as of today in the fund are thanks, in part, to a good communication, and that includes those roadmaps, that allow studios and artists to know approximately what to expect and approximately when to expect it, without good and proper communication the development fund will be damaged.

So I understand your points, and I agree from a developer perspective, but now that even the weekly meetings will probably disappear, this proposal should come with an efficient communication proposal too, and that means that not all the communication decisions should depend on the modules owners, because then we will go back to not knowing what’s happening, just because it’s hard to be an efficient communicator when you are buried in things to do and no one is pushing you to dedicate proper time to that.

So in the end, I agree,m but light should be periodically shed into the progress of each module and the roadmap, even if it’s feature driven and not release driven, and the communication IMHO should be centralised in one responsible person or team that should compile the adequate information and update it on a monthly basis for example, not each module owner, or this will be a communication mess I’m afraid, and that could potentially damage Blender in the mid term.

[ideasman42]

+1 to use easily editable text, at the moment if there is some change to plans, it’s not practical to edit the SVG (feels like busy-work).

I think users appreciate seeing some kind of a time-line for whats planned though - which the current SVG’s communicate quite well. So it would be good if this could be captured with whatever we use to replace it.

Possible headings:

• Ongoing Projects
  Larger projects which are being actively developed.
• Release Targets
  Which are being actively developed & planned for the release.
• Future Projects
  What we plan to work on next.

[RonanDucluzeau]

Users and contributors simply want roadmaps to be able to organize themselves, by anticipating what will be situation in upcoming months, upcoming years.

I know that developers don’t know the future.
But the person the most aware of what time is needed to deliver a work is the worker himself.
People want an estimation. Whatever the job is, everybody has to do that in any field, in this world.

People expect that you indicate if you estimate that such job will be done for next month, next trimester, next semester, next year or in 2/3 years or at the end of the decade.

You don’t have to be right for your first try.
Your estimation will become more and more reliable while your experience will grow.
You have the knowledge of your methodology. You can evaluate the steps you need for a project.
You can make comparison to work that you have already accomplished.
You can ask more experienced developers how many time they spend on comparable tasks.
There are lots of things that you can anticipate. There are several things that you can’t anticipate.
You can add a margin of security for the unexpected problems.

What you have to do is to update your estimation regularly, every month or every trimester and to communicate when your priorities are changed by an event about why they are changing.
People want to know for how long previous priority will be postponed or if it will be abandoned ; or if you don’t know, when you estimate you will have an answer to that question.

We don’t expect promises. We are just expecting you to be as frank as possible.
That is an open project.

[JuanGea]

@ideasman42

. So it would be good if this could be captured with whatever we use to replace it.

A simple solution could be to generate something similar to what is there right now but generated via HTML, so the data is just text, and it’s changes are reflected in a “gantt like” chart, like the current SVG, but automatically generated, that could be easy

Something like the dynamic bar in the dev fund, I’m sure you already have the solution, but just in case here are two possible opensource javascript libraries:

Chart.js

Chartist - Simple responsive charts

[julianeisel]

I also kind of agree with you, but some things I could/should be addressed differently I think.

@JuanGea

But at the same time I think there is one important point missing, efficient and clear communication with users.

A rather broad comment, and I don’t disagree. Blender has a very open process IMO, yet it is lacking in some regards. Like you say, some modules make it less of a priority than others.
It’s also not just a matter of communicating plans better. A dynamic, loosely planned process has its merits too, which agile development ideas try to respect. Of course, good planning sounds good on paper, but may not always be in the best interest of stakeholders. To be clear: I’m not saying planning isn’t important. But many of the greatest achievements in Blender aren’t exactly examples of well planned development.

There are modules doing regular meetings, followed by meeting notes - generally quite detailed I’d say. Goes a long way, but even that has some issues.
The module landing pages on developer.blender.org seem like a reasonable place to note general priorities and projects. We just don’t make good enough use of it yet. Plus, we need a better way to announce changes.

---

Further, I think Blender Institute/Foundation certainly bear a good chunk of the responsibility here. Not just to intervene where modules don’t do good work.
But there’s the question of how we want the BI/BF to work with the modules. Currently, there are proposals to organize things somewhat like the following (in my own words):

• Strategical tasks. (“Edit mode should be much faster!”)
  The BF/BI can define these, in collaboration with modules. BF/BI should be responsible for the communication I think.
• Tactical tasks. (“To get edit mode faster we can try doing x, y and z”)
  The module takes responsibility for the tactical aspects of the strategy. Communication included.
• Operational tasks. (Regular development, bug fixing, review, docs, release management, etc.)
  The module does this, possibly with help from BI/BF. Can be organized on workboards for example.

---

So all things considered, I think if the module landing pages note the strategical tasks and the tactical priorities, plus we find a good way to announce changes, that would be a good improvement.

[julianeisel]

@ideasman42

I think users appreciate seeing some kind of a time-line for whats planned though - which the current SVG’s communicate quite well. So it would be good if this could be captured with whatever we use to replace it.

Possible headings:

• Ongoing Projects
  Larger projects which are being actively developed.
• Release Targets
  Which are being actively developed & planned for the release.
• Future Projects
  What we plan to work on next.

Yes, if we find a good way to indicate status (without the tendency to get outdated like the current SVGs), that would be good.

Your proposal seems worth a shot, let’s try this for the UI module.
Interestingly it also kind of reflects how the individual tasks are organized on the UI workboard (release columns, Short-Term Scope (Active), Long-Term Scope (Active)).

[JuanGea]

I agree with you en everything except in one thing, the usage of developer.blender.org

It’s not an attractive website for users / communication, in fact it is a technical website that for users is kind of frightening, so while it can be used, it may have a less frightening presentation.

And here is where I agree with you again BI/BF is the best conduct to maintain the best possible communication.

EDIT: BTW I love Agile/Scrum and the best thing it has is that nothing is written in stone and things change from effort to effort, and that’s good, that also makes the communication effort important to not allow users become crazy

[dan2]

I don’t mean to intrude, just 2 cents from a user point of view.

@ideasman42

I think users appreciate seeing some kind of a time-line for whats planned though

Definitely, a timeline is super helpful for users as well as studios.

Projects being simply tagged as long term/in process not so much, as they can drag for many years. Good to know they’re on the road map, but if it’s planned for 3-5 years from now it’s not relevant information for most people, techniques in the industry are changing too fast.

I of course understand not wanting to have the overhead of maintaining SVG files periodically.

Thank you for keeping the development so transparent, it’s really interesting to keep track of.

[RonanDucluzeau]

@julianeisel

But there’s the question of how we want the BI/BF to work with the modules. Currently, there are proposals to organize things somewhat like the following (in my own words):

• Strategical tasks. (“Edit mode should be much faster!”)
  The BF/BI can define these, in collaboration with modules. BF/BI should be responsible for the communication I think.
• Tactical tasks. (“To get edit mode faster we can try doing x, y and z”)
  The module takes responsibility for the tactical aspects of the strategy. Communication included.
• Operational tasks. (Regular development, bug fixing, review, docs, release management, etc.)
  The module does this, possibly with help from BI/BF. Can be organized on workboards for example.

I think that your example is showing how having a transversal topic repeated in several sections is confusing users.
Tactical tasks and strategical tasks have to be exposed on same roadmap.

You know that your plan should work : display a line.
Tactical task 1 → Tactical task 2 → Strategical goal

You have several tracks to make something : draw a tree.
Tactical task A – Tactical task 1 -\
Tactical task B – Tactical task 2 → Strategical goal
Tactical task C -/

If a tactical task has an impact on several strategical goals : just repeat it on several diagrams.

You can not just expose a list of tasks and expect users to understand which are relations between them.
If you follow that suggestion, you have to indicate for each on going task and following one, an estimation of date of delivery.
If the strategical goal is not supposed to be reached in the upcoming 2 years, don’t do any diagram.

[Harleya]

Personally I think that the roadmap images represent something we’d love to provide, and that users would love to see, but just isn’t possible by the nature of the project.

Why it isn’t possible is easy to understand when you look back at existing features and old goals with the benefit of hindsight. When did we know, or did we even know, that it was something that we would get? When did we know that someone started working on it? Was the time taken until completion something that could be predicted. How soon before it was finished did we know it was going to be finished? Was the time between when it was finished and approved a predictable amount of time? At what point did we know which release it would land in?

So I think doing “module roadmap images” better, is to understand what they represent to users. Typically a user is looking at that page with nervousness and hope. They are using a program that they like, and feel it could be better with improvements. They mostly want assurance that the project is moving forward, changes are being made, errors being fixed. They worry about stagnation, lack of focus, and about the possibility that what they care about will not be improved.

So we mostly just don’t communicate the health of the project, the amount of activity, the rate of change. How much more total work is being done right now, compared to the past? Are problems being addressed? Are things improving quickly?

But we do a terrible job of communicating such things. I think a good first step is to not use a Phabricator page as module home pages, and instead keep such things on the wiki. So basically clipping each section out of the Modules page and moving those to new pages. That easily-edited page can then contain goals, projects, links to developers, and to much more detailed and more interesting information. I might even do that myself if we were to have a community artist donate a set of banner images that could be used to represent each module.

[kosirm]

I agree with every point of your post, but please don’t forget that “A picture is worth a thousand words”.
Ideally SVG should be created on the fly from module descriptions and dates. It’s a bit of javascript or something… just my .2 $