[steamer_ctn]

I would like to add a few thoughts to the discussion.

My OR Involvement -
My reasons for getting involved with OR were because I believed it had great potential, and specifically
i) It was going to reuse models, and routes that I had already produced.
ii) It would hopefully have better features (in my case better physics) and correct some of the problems that were in MSTS
iii) It was free

MSTS Compatibility -
I liked the concept of being able to use MSTS models and routes (more the models then the physics), but I have personally been frustrated with the concept of trying to maintain 100% feature compatibility with MSTS. We need to bear in mind that MSTS appears to have almost been a beta release, and therefore the implementation of some of its features were not fully operational or correct. Over the years since the release of MSTS, this has been overcome in part by some very smart people who have developed work arounds. But by trying to maintain these work arounds in OR I believe that we are perpetuating the issues that MSTS has created.

To use an analogy, "putting old wine in a new wine skin, does not create new wine".

Paid Developers -
Whilst I don't have any philosophical issues with the concept of paying developers the question would need to be asked as to how this would be funded? Certainly one model is to adopt the same approach as other simulators, and charge a license fee.

In my case this would reduce some of the attraction of OR, and if I was going to pay for it, then I would need to do a comparison of all simulators to determine the best value proposition to invest in.

Developer Recruitment -
When we talk about developers most people think in terms of people who code OR.

To add a new feature to OR a "developer" needs to undertake a series of tasks similar to the following:
i) Complete administrative documentation such as blueprint, etc
ii) Research prototypical material to understand how the feature works
iii) Develop a software algorithm (ie work out how it can be coded )
iv) Test the proposed implementation
v) Commit the change to OR
vi) Update the manual and supporting documentation
vii) Provide ongoing support and advice as appropriate.

As can be seen from the above list of tasks, the effort required by a developer in adding a new feature can be quite large and in some instances may act as deterrent for somebody thinking of adding a feature.

Thus I would like to suggest that a broader approach to the issue needs to be considered.

I believe that we should be taking a more holistic approach, and rather then just focusing on people who can code we should also be recruiting support roles that will move some of the load and effort away from the coders. For example, who could provide some of the administrative support, who could help with testing, who could help with writing the manual, etc?

Content Creation -
If we consider a broader approach, then how about content creation?

We appear to have some skills in the community in regard to content creation. How about encouraging the creation of new content, and also conversion of existing content to work more effectively in OR, rather then trying get OR to operate in "MSTS" mode?

This could also act as a way of demonstrating OR's greater potential compared to MSTS, and clearly show that OR is not "tied" to MSTS.

Model Configuration -
Part of the issue with MSTS was the need to develop workarounds when configuring ENG and WAG files, which in turn sometimes made the setup of these files very complicated. This was often beyond the skills of all but the most dedicated train simmer, has resulted in a lot of poorly defined ENG and WAG files.

For me this has highlighted a need to provide some good "how to" notes and working models to demonstrate how different features can be implemented. My contribution to this aspect is here.

Conclusion -
So in conclusion, I would encourage that recruitment consider a bigger picture view that doesn't just focus on developers (read OR coders), but all the relevant supporting roles that could be leverage to successfully develop OR. Coding is only one aspect worthy of consideration. This approach might also reduce the "developer" workload, and encourage other coders to contribute.

Our community has many people with many different skills, we need to be thinking about how we can engage all these skills into the right roles rather then trying to just engage developers to do everything.

Everybody in the community has the potential to contribute in some way.

Thanks

[cjakeman]

Very pleased to see such a busy thread.

Thanks to James, Edward and Rob for commenting on their own joining experience.

cjakeman, on 23 April 2017 - 12:15 AM, said:

We can look at this 3 ways:

• more developers
• more productivity (i.e. achieving more for less effort)
• more skill (programming is complex and there's always more to learn)

So we've looked at Point 1 - more developers - and made some proposals: a recruitment campaign through the website and prompted by the OR software and supported by the switch to Git and hosting the repository on GitHub and also supported with some first-time-only tasks for new recruits and mentoring. We'll be especially keen to find coders with experience in content creation.

Several people have commented on Point 2 - more productivity. James thinks that switching to Git will help and although our code has grown, I think it is now better structured and easier to navigate.

When I started, Chris van Waggoner found me a mentor and a simple task to tackle. The mentoring was hopeless but the task was well-chosen and gave me confidence to stick with it. For the last 2 years I've been working part-time with a colleague who lives 30 mins away. As well as sharing files and a repository, we communicate through Skype which provides text-chat and voice. I've used it for 3-way calls and for sharing my screen (although I prefer SplashTop as a high-performance screen-sharer). There's also Slack which is great for text-chat about a small project and sharing files.

Steamer_ctn (Peter) wrote positively about team members collaborating - he had a lot of modelling support from Copperpen and, way back, I had a lot from Buttercup (Eric) over activities. My point is that this is much easier now than it was a few years ago and, Peter's right - we should be working together much more. It will certainly help with mentoring new recruits.

[rdamurphy]

Well, I've been kind of lurking on this topic, and well, I guess I should through out my 2 cents worth...

Um, the blueprints - not that complicated, pretty self-explanatory, and honestly, I think we need to not work on the same things at the same time... Been there, done that, once, on a sound issue, and it really caused a lot of problems, my apologies for those that remember and were involved...

I don't know how many programmers are in the MSTS/OR/Train sim community, but I can't imagine, with C# being a relatively new language, that there are really that many. Honestly, I'm a VB/VB.net guy, I had to learn C# as I went along. Still learning... The concepts in most computer languages are the same, variables, constants, functions, if/then, select case, loops, etc...

I know there's some great ideas out there, but I think there are enough strictly content creators that programmers really don't need to do that also... Maybe if we could "hire" some people willing to do that part?

But, first, route and activity creation tools...

Hmmm, everyone's right, there IS a lot of work to do. I wish I had more time, but...

Robert

[Csantucci]

So I noticed that I still didn't answer the question of this thread: how did I get involved in OR? I started filing a bunch of bug reports in Launchpad, and Chris noticed me and wrote me. I don't remember whether I started suggesting some bug patch before of after being contacted by him. Anyhow this led me to admission to the ET developer's group.
And now the lesson about this: there are cases of people having suggested patches in Launchpad (maybe also here in the forum) and not belonging to the ET developer's group. I can remember at least 2 or 3 that probably haven't been contacted to see if they could enter our group. We (Chris?) could search for their contributions and contact them, although for sure it'd be better to contact them just after their contribution, that is in a moment where they for sure are motivated.

[cjakeman]

Csantucci, on 29 April 2017 - 11:04 PM, said:

We (Chris?) could search for their contributions and contact them, although for sure it'd be better to contact them just after their contribution, that is in a moment where they for sure are motivated.

Thanks for your answer to that question, Carlo.

And I'm happy to follow up recommendations . . .

[cjakeman]

cjakeman, on 30 April 2017 - 10:21 AM, said:

And I'm happy to follow up recommendations . . .

I've already received several so, thanks, guys. That's very helpful.

[cjakeman]

I've created a blueprint at Launchpad.net for the combined task of recruiting and supporting new developers. You can see it at https://blueprints.l...-new-developers I've also listed some of the work-items involved.

The blueprint contains a link to 2 simple mock-ups:

• a pop-up for Open Rails Menu.exe
• two pages for the website

Comments would be welcome.

P.S. This is quite a big task, but worthwhile I think.

[cjakeman]

cjakeman, on 01 May 2017 - 11:28 AM, said:

• a pop-up for Open Rails Menu.exe

Comments would be welcome.

The pop-up might look something like this and perhaps pop up for the first time when the user exits from RunActivity.exe for the 10th time.

Attached thumbnail(s)

• 

[jim]

cjakeman, on 02 May 2017 - 10:00 AM, said:

The pop-up might look something like this and perhaps pop up for the first time when the user exits from RunActivity.exe for the 10th time.

GREAT IDEA!!! all for it.
thank you
jim

[SP 0-6-0]

Excellent!

I might suggest a better effort to keep the ORTS site current if at all possible? Right now the system specs are outdated. ORTS struggles on those minimum specs. Atleast for me.

I currently have a MSI machine with a 3Ghz duo core cpu and 3GB of ram with a Radeon HD5550 graphics card with 1GB of ram and a 1TB Seagate HDD running Windows Vista Home 32bit. ORTS is slugglish in the video playback and FPS are very low. FPS are in the 20's to 30's range.

Robert