[cjakeman]

In the past, the Project Roadmap has been published in several forms.

We have short summaries of each milestone listed at Launchpad.net but these make it difficult to get an overview.

We also have the Trello cards, which offer voting so we can sort them by some sort of priority. But the large number of cards makes it difficult to get an overview.
The OR Management Team (i.e. James and I) have been through the cards and assembled a table to provide an overview. We thought it was important that the project should have a roadmap small enough to fit into a single screenful.

A first draft of this overview is now published on the website and we hope you will comment on it and help us refine it further.

Please bear in mind that the precise timing and sequence of developments is never fixed but depends on the time and talent of our volunteers.
Please also bear in mind that there isn't room in a single screen for every feature. 33 are currently listed; I hope we can keep it to 36 or fewer.

[Genma Saotome]

Well done Chris.

Only thought that comes to mind is to ask about the availability of any Direct X standard not presently used. It might be implied in "Better looking water" but that is not mentioned in the trello card.

[steamer_ctn]

Hi Chris,

Thanks for your work on this, but personally I believe that we should be presenting the roadmap in a different format.

As you have rightly suggested OR is a volunteer project, and hence developers are not assigned to work on specific features such as in a commercial project, instead they tend to work on their areas of interest. So in this type of environment there is very little guarantee that a particular feature will be completed for a particular version. Thus I think that we should move away from a roadmap that suggests this, and builds a corresponding expectation. I think that this approach has a high risk of failure, and will continually damage ORs reputation when targets are not met.

Instead I would suggest that we group future features into a number of categories, such as "highly desired", "desired", etc. These would then provide a pool of features that have been identified and may/will at some stage be incorporated into OR.

In addition to above pool, we could then just have the next version shown on the roadmap, and beta features added to the unstable version could continually be moved to this list until the version is released. In this way the next release version will be growing with confirmed features, rather then "wish list" features that may never eventuate.

In this way we could do annual releases based upon the features included, rather then holding a release back til a roadmap feature is completed. I think that this approach would provide more user confidence and credibility for OR.

[Weter]

Very nice, pretty little table.
It promises so much of everything wanted and tasty!
I agree with Peter completely.
Yesterday I would write almost the same, but what did prevent me is that I had nothing to offer in turn.
Now, Peter offered quite good alternative for that.
Here are some highlights:
1.

Quote

this approach has a high risk of failure, and will continually damage ORs reputation when targets are not met

2.

Quote

"wish list" features that may never eventuate

Certainly, these both potentially can distract some followers.
3.

Quote

holding a release back til a roadmap feature is completed

Indeed, the less-advanced users, who don't see any distinctions between unstable and testing versions, will probably ask such question: "The project is likely dead, as the last STABLE VERSION (1.3) was introduced even at 2018, isn't it?"
Even here, at ET boards, how many members, who reporting bugs are using 5-6 years dated versions of ORTS! After they were asked: "why don't you use last testing version, free of said bugs?", they are often surprised a lot, that such version even exists.

---

One more note:
Reading of that improvements list, derived from GitHub is really tedious, even if contributors wrote their descriptions perfectly (I do have that sin as well)
Tedious even for advanced users, as I am: pr#xxx from Paolo Korbuzzi bug ##Yyy from mounchpad.zet fix issue with blah-blah at version gal098765n3f4 etc. 1000+ strings total...
But I need to know, has it sence to download given testing version, or wait for next one-and I force myself.
Plain users wouldn't do that! I think so.
Then, please, think about that: is there any possibility to post news about significant features implemented/odious bugs fixed, a little more frequent, than once per year.
Before I started working with ORTS translation and went here, I interested only that two things, when opening download page of openrails.org : version number/date and recent news.
Over.

Please, forgive my irony. That is just an attempt to advocate regular openrails.org visitors position. I'm sure, that multi-layer subpages as Learn, Discover, Meet etc. are very precious and interesting (instead I didn't spend my time to translate them and load texts here), but for enthusiasts at most. Again, the majority of users, especially newbies, will come and download ORTS program. Maximum, compare version number.

Maybe, as we will guess that balance, I will no longer hear that offensive comments, like: "that abstruse openrails that Americans make for themselves"
So, maybe less of nice promises declared, but more of real advances announced?

[James Ross]

 cjakeman, on 10 June 2021 - 10:15 AM, said:

A first draft of this overview is now published on the website and we hope you will comment on it and help us refine it further.

Please bear in mind that the precise timing and sequence of developments is never fixed but depends on the time and talent of our volunteers.
Please also bear in mind that there isn't room in a single screen for every feature. 33 are currently listed; I hope we can keep it to 36 or fewer.

 steamer_ctn, on 10 June 2021 - 11:55 PM, said:

Instead I would suggest that we group future features into a number of categories, such as "highly desired", "desired", etc. These would then provide a pool of features that have been identified and may/will at some stage be incorporated into OR.

We were not sure whether to include the proposed version numbers on the roadmap. However, it is worth noting that, no matter what we label the groups, there are some ordering requirements, so pure desirability is not giving the whole picture either.

Let's just take the version numbers off for now.

[Weter]

Well, OTOH, the release of version with given number would be a clear sign, that given features are debugged and implemented already.

[steamer_ctn]

 James Ross, on 13 June 2021 - 03:19 AM, said:

However, it is worth noting that, no matter what we label the groups, there are some ordering requirements, so pure desirability is not giving the whole picture either.

Let's just take the version numbers off for now.

I agree that there is an implied "ordering requirement", however by not having version numbers we are not setting specific implied timelines.

Unless we can guarantee a developer will deliver a certain feature in a particular version, the feature should stay in the "pool(s)" (in whatever format is best).

I still think that we should just show the next version as the only specific timeline. So for example, when v1.4 is released, we should have v1.5 appearing on the roadmap, and then move features to it from the "pool" only as they are completed in the Unstable version. No other version numbers would appear on the roadmap.

This will give users confidence that OR is still being developed, and also allows content developers to plan content releases for the next version.

[cjakeman]

 steamer_ctn, on 10 June 2021 - 11:55 PM, said:

In this way we could do annual releases based upon the features included, rather then holding a release back til a roadmap feature is completed. I think that this approach would provide more user confidence and credibility for OR.

 Weter, on 11 June 2021 - 04:51 PM, said:

Then, please, think about that: is there any possibility to post news about significant features implemented/odious bugs fixed, a little more frequent, than once per year.

The v1.4 was indeed held up until Monogame was ported. I see that delay as an exception and we certainly want to release versions more frequently - perhaps every 6 months. Using "release candidates" should make this easier to achieve.

 Weter, on 11 June 2021 - 04:51 PM, said:

So, maybe less of nice promises declared, but more of real advances announced?

The "real advances" are already there on the website. For v1.3, see http://openrails.org...er/version-1-3/ and we have been planning ahead. So for v1.4, see http://openrails.org...er/version-1-4/

 steamer_ctn, on 10 June 2021 - 11:55 PM, said:

I agree that there is an implied "ordering requirement", however by not having version numbers we are not setting specific implied timelines.

For example, deferred rendering of graphics will be needed before we can deliver multiple light sources and ambient occlusion (and possibly realistic water too).

[cjakeman]

 James Ross, on 13 June 2021 - 03:19 AM, said:

Let's just take the version numbers off for now.

I've left v1.5 at the top of the table and removed the others.

[cjakeman]

 Genma Saotome, on 10 June 2021 - 11:20 PM, said:

Well done Chris.

Only thought that comes to mind is to ask about the availability of any Direct X standard not presently used. It might be implied in "Better looking water" but that is not mentioned in the trello card.

Thanks, Dave.

I don't know enough to answer this question, so I hope James can respond.