Call for Development and project management.

[Max-Max]

Hello everyone.

You are, as probably the most of us, in this thread because you have a great idea to share. Maybe you hesitate to start on a project because you don't know if some one else is already secretly working on the very same thing.

I propose that we create a new forum section, for example "Simutrans projects" and one thread (sub forum?) for each major project in progress.
If the core team, today, gives their "blessing" to the project and say, "Hey what a great project, we will take this into the trunk upon completion" I think this will work as an carrot for the community if they know that the project will make its way into the trunk.

In each project thread, create a sticky describing the goal, road map and the people involved in the project. To make the administration more easy, point out one or two moderators to maintain the forum, such as update the list of developers, goals etc...
This approach makes it easy for us to see what's going on and what the goals for each project are.

If you feel that there are things that needs to be done, for example improving the font handling, create a new project thread and announce in the sticky that developers are needed...
This will bring a little bit more order to the projects and hopefully the progress will go faster when everyone is working in the same direction.

With this said, people can still run their own projects, but at least everyone can see what's going on.

- "But we have already a forum for projects"

This is true, but some of them aren't pure development and most of them lack the description and goals for the project. As an example, pick a function. Now try to find everyone working on that function or similar function. You will have to scan through all the threads because the subject may have changed during the discussion, and in the end who is working on it?

So lets assume I (in this example Mr W) have an idea for project X that I would like to work on.
I create the thread "Project X" in the project forum and then writes a sticky.

Project X

Description
I want the letter X to be banned from all text and graphics. Whenever the letter X shown in text, it shall be replaced by the letter Y. If the letter X is in a picture it shall be covered by a black box.

Repository
http://project.repository.com

Road map (tasks)
1. Modify the translator to scan for the letter X and have it replaced with Y.
2. Modify the image reader to analyse each picture to recognise the letter X.
3. Paint a black box over the X when loading the image.

Goals
Ban the letter X from Simutrans so it can't be seen anywhere..

Team
Mr W (moderator/admin)

To begin with Mr W is alone in this project but anyone interested can have a discussion about it and join. Madame Z wants to join the team so Mr W updates the sticky.

Team
Mr W (moderator)
Madame Z (moderator)

Madame Z and Mr W can now split the task between them and agree upon changes and implementation and still have a discussion with the community.

To be honest I would like to see something like an online project management system so developers, assigned tasks, changes and bugs can be tracked. If someone knows one feel free to contribute in the matter.

If we can solve it here in the forum it would be grate too. Well this is just a proposal in a try to make us developers more organised and work in teams pulling in the same direction, rather than secret individuals with great visions pulling in all directions at once.
The discussion is open

[Ters]

Some projects have been given their own sub-forums, but they have to show their worth first. Otherwise, I fear we'd be overcrowded with sub-forums with a single thread containing the post you show an example of, a few posts of cheering, and then silence. The trouble with finding out if others are working on the same might be more related to the fact that we often don't say much until a working demo is in place. Having a long history of abandoned projects behind me, I'm wary of giving people false hopes of something actually being done.

[kierongreen]

Projects have tended to be the work of one person so far. I think that any project that needed more than one person to create would be a real pain to integrate with the rest of simutrans anyway as it would be huge!

[Markohs]

I can see the advantages of your proposed system, but with the current number of active developers, that's 5 persons, I don't think it's worth making this. We are ok atm as I see it, with just 1 thread for every project.

[jamespetts]

This is an interesting thought. It is certainly a very good idea in principle for people who are working on a project to let other people know using the forum that they are doing so to avoid duplication. I am not sure that we need a system as formal as is proposed. What might work is a request posted as a sticky in the development forums (for Standard and Experimental) that those embarking on projects beyond early exploratory stages post a thread to let others know of what they are doing. I am not aware that there has been any significant issue in the past with duplication, however.

[IgorEliezer]

I think there's an interesting bandwagon effect in this.

While this might not have a practical use, for now, other people would see what's going on and would feel motivated to participate in the development of new features and bug hunting.

[Ters]

But do the developers want a bandwagon? Some (most? all?) projects are simply the occasional pastime of developers who like tinkering at something without any commitment. Nothing is stopping those who do want a bandwagon, and there are such threads, even subforums (mostly in the pak department).

The trouble is that projects don't always start out with a clear goal, and those that do, often snowball or change focus. Starting a new thread with a new introductory post might be better for new readers, but breaks the flow for those already in the discussion.

Another problem is that the Simutrans community lacks leaders, and I feel that potential leaders have a hard time winning over the existing community. There is somewhat of an evil circle, I think, where we can't improve without growing and we can't grow without improving.

[prissi]

As the "leader" part probably aims at me, my five cents: I am personally not sure if a tighter leadership will benefit the program development. Because, this would imply that there are enough people willing to be led. The five or so contributing in good times certainly did not require leadership. And then I might have done better at the few times when leadership was required before splitting of experimental (although this might be beneficial in the long run) and the Hajo desaster. But I am still not sure what I could have done other at these times.

On top of that: most contributors to Simutrans were pretty equal or even above my personal programming skills. So how could I assume a tight leadership? I will offer my comments, and for third person patches, most will finally integrated by me (but any other developer could do this, like Dwachs did a good job on the statistics).

In the end the open discussion about including (and then how to include) did work since there was a steady team of more than two developers. So simutrans is something democratic (if you got the developer status, i.e. are ok to commit to the codebase). The latter I (or some other developer) could grant on request any person who had made, lets say three patches and contributed for at least half a year.

If there is a capable person who wants to take lead in Simutrans coding, I would happily step aside (my family and my job leaves me with less than 1-2 hour at most for daily Simutrans). But most other coders are also involved with real life, and none volunteered so far.

So back to the question of leader: So far most Simutrans projects (pak128, pak128.britain, experimental) are similar to the coding. They have somebody who took on most of the work and thus got a final say. Still they are very open to contributions. As such the Simutrans way seems rather a very loose leading.

I have studied many different things in live, but coordinating a software project was rather something thrown at me. So I am very open on suggestions for improvement. And if we could appoint a patch coordinator, who finally start to integrate patches (after we came to a conclusion how they should be integrated) I would be very happy.

[Max-Max]

I think I disagree a little bit here. Simutrans have some unofficial leaders; the core development team that decides what is and what is not to be included in the main trunk.

As a developer, I want my work to be recognised and as long I don't know if my idea will be included in the main trunk or not, there isn't much point in developing it. Sure I can make a patch but it will break at some point when the trunk moves on...

I know of at least one very good example of open source development that successfully releases a steady stream of solid breakthrough technology in their product; Blender. They have a strong front figure with a vision but as a community anyone is free to develop the software. They use Google Summer of code to get hi-tech features into the software like camera tracking, video effect and post production. Other volunteers have written entire physic and smoke simulations to Blender. Blender has become a strong competitor to Maya and 3D Max offering the same functions and more, completely free of charge.

Okay, they do have some money, mostly donations and at occasions they hire temporary to boost development from time to time. But this isn't critical to move Blender forward. They usually announce a cool feature with a price tag and then run a fundrais until the goal is achieved. They also offer a DVD with blender (even if it is free to download), but as a DVD buyer you also support the development.

I'm not implying that Simutrans is even near the size of Blender, nor possible to sell Simutrans items or pay people to do some development, but the project is very successful.

Okay enough of the ranting

So how can we improve the Simutrans development?
I had a look at the forum system over at simplemachines.org and we could make use of some features.

1) Categories.
I don't think categories is enabled, or I may have miss understood what they are. But we could have categories like, patch, project, bugs, features etc... I would imagine that you could filter your search on these categories and get a more narrowed down match.

2) Polls.
Announce major projects as polls to see if there are any interests of a specific feature.

3) Project updates.
Lets assume we stick with the current system, but tags a project with the category "project". Provide a template for a project header that will be a sticky. I don't know if it is possible to have the creator of a thread to get the "sticky" rights. It would also be reasonable that the creator of a project thread also maintains the sticky.

The sticky would contain the project goal, development team and description.

If we don't use the category feature (or I have miss understood it), we can code these project threads as [PROJECT] project name in the subject field.

Now, since we do have an unofficial leadership, and "they" do decide what is going into the main trunk or not, "they" can show their support of various projects by announcing that this project will go into the trunk if it full fills the description and goals as described in the sticky. Should these goals change they have the right to reject the project. But it can still be released as a patch, the usual way.

A dying project will bubble down when people stop to write in the thread and the sticky isn't updated any more by the project "owner".

[kierongreen]

Requests, projects and patches are categorised as considered or denied by the dev team already. However just because an idea is considered doesn't mean that if a patch is written it will be incorporated into trunk - it might affect performance too much, or have design flaws for example. Equally an idea that is denied as being impractical might be incorporated into trunk if someone puts together a patch that works.

Patches do suffer from bit rot as time goes on (as do git branches before someone shouts about that). The onus is on the patch developer to keep it syncronised with the trunk code.

There's nothing to stop someone asking for money to code a particular feature incidentally - or offering money for someone to code it. Whether anyone would actually write code for simutrans for money, or contribute money I have no idea though!

There's not a formal system of voting on ideas but a view is formed after looking at the discussion surrounding it. Views from the dev team are bound to carry more weight than those of other members, however there have been occasions when an idea has been incorporated into trunk against the wishes of prissi or other developers simply because of popular support (e.g. introducation of elevated ways).

Basically everything you suggest can be done in the existing structure of the forum, and indeed is how it works more or less.

[Markohs]

The trouble is that projects don't always start out with a clear goal, and those that do, often snowball or change focus.

haha this sounds familiar.

[Max-Max]

I still think we can improve this a bit more. I think a sticky with the project description and goals will generate some bandwagon effect.
Yes, spec. will change, but with an updated sticky, you don't need to scan the whole thread to understand what the project goals are, who is on it and how far it got.

I can also think of at least one project that in the end needs to be done to attract more developers; translate the code to English.
Yes it will likely break a lot of patches, but I think it is a necessary evil that has to be done at some point. Not that I haven't anything against Germans but I do have a hard time to understand the code sometimes, just because of the German names and descriptions. It took me quite some time to track down where the toolbar code was located.

However, back to the subject... Do someone find anything of this useful? Can we try something to see if it improves the project structure?
I would say a sticky would be a bare minimum to at least try...

[Ters]

My impression of lack of leaders was because nobody actually applied for the job. From what I understand, prissi just suddenly found himself in the role, and there have been no better candidates IMHO, for various reasons. By leader, I mean someone who can devote a lot of time to oversee everything and preferrably also is one of the most experienced programmers. The current leadership is comfortably tight as it is.

There are differences between the way Simutrans is run and several other open source projects I know. Perhaps the most obvious to me as a developer (in the general sense, I haven't actually programmed much Simutrans) is the issue tracking. But the more we formalize things, the more pressing things feel. Seeing the number of open issues in an issue tracker rise and rise is depressing for both sides. Trying to set goals for each version would be counterproductive without developers committed to doing things on a time schedule.

We can, and I think we do, encourage people to post what they are up to. What else is the Large projects board for? But we can't force people to post there. The trouble is that we can easily overwhelm the board with stickies if we make the threads that, many of which are dormant, yet not wholly abondoned.

[IgorEliezer]

But do the developers want a bandwagon? Some (most? all?) projects are simply the occasional pastime of developers who like tinkering at something without any commitment.

Probably I chose the wrong word. What I mean by "bandwagon" is, if people outside see there are some activity, they will feel motivated to follow and contribute.

[Ters]

That is the meaning I understood it as. I might not want such a thing, where I have to coordinate with others and feel that others are anxiously waiting for me. There's enough of that at work and other parts of my life.

[IgorEliezer]

I might not want such a thing, where I have to coordinate with others and feel that others are anxiously waiting for me.

By chance have we chosen those who will coordinate anything?

That's why I had proposed a board for testing builds a few weeks ago. If someone joins, creates a feature and wants to receive some feedback, he/she can release a "custom" build and won't need to wait for the inclusion in the trunk to see it running, unless if it appeals the devteam. None needs to feel under pressure.

In other communities that I know, it's pretty common to find variants, branches, mods, addons, plug-ins, patches, custom EXEs or EXE mods from the main game or software. Blender and Minecraft are good examples: some users develop by their own a new feature, make a build (or EXE, Python, jar) and release it. It's up to the devteam to pick it up and include in the trunk; if not included, nobody will complain nor will the devteam feel guilty for doing so.

In fact, I'm trying to simplify Max-Max's idea a bit by not putting any task over dev's shoulders. Developers could write what could be interesting to be done by casual volunteers, but you don't need to be a guide of them.

[Sarlock]

Going to chime in with a few thoughts:

I love the leadership structure for Simutrans.  It's subtle and very open but it's still there when it needs to be.  While having someone with 40 hours per week to devote to the game would be wonderful, we all have families, jobs and other priorities in our lives.  We're all busy individuals and I think the least amount of administration and overhead, the better.  What precious hours we do have for devoting to the game should be spent developing, not updating schedules, lists, etc.  We're supposed to have fun doing this

Most of the major coding projects do have their own threads: half height, map edges, etc.  Once a project progresses enough the coder will naturally seek the input and opinions of their fellow coders to help it take shape.  The game code is so huge that no one person can be familiar with all of it and so it's important to draw from everyone's individual experience in order to develop something.

If we had a larger coding group it would certainly be necessary to be more coordinated but I think at this size it's better to just focus on the coding and stay loosely organized.  It took me a few months to figure out how things work here but I am quite happy with how it's organized, I continue to be amazed at how smoothly this group works together.  I think the lack of formal structure helps in that respect.  It also contributes to people staying around for a long time... there are no pressures, deadlines, etc.  It just stays fun and casual.

I think of my own pak128 projects: I probably have 20 things going on currently and only 3 or 4 of them will probably ever be completely finished.  I imagine most coders operate the same way.  I'd hate to have to catalogue/track all of these.

[greenling]

Hello Sarlock
I self come at my projekt only slowly forward.

[Max-Max]

I don't think I ever proposed a time schedule...
But at least a project description and the team working on it.

My last proposal with a bare minimum of [Project] ProjectName in the subject field and the first post to contain the project description and team can't really put any pressure on any developer?

I did test to edit my first post in a thread and it works fine to update both subject and content, so we don't need it to be sticky. Just remember to reserve the first post as the project description.

I can only see advantages with this.

1) It is easier to browse among the different projects.
2) You can see how many people are involved.
3) You can quickly see what the project is all about. If you have a similar idea you can join that team instead of working in secret to discover you have done almost the same work as someone else.

With this said, you CAN of course work on your own secret project if you want.

[Ters]

1) It is easier to browse among the different projects.
2) You can see how many people are involved.
3) You can quickly see what the project is all about. If you have a similar idea you can join that team instead of working in secret to discover you have done almost the same work as someone else.

1) This is very useful, although a disappointment when you find the last post was two years ago. But I think we have this already, to what extent we're able or comfortable.
2) So far, this has pretty much always been one, sometimes zero, apart from senior developers tidying up at the end. But it is perhaps changing. I think there are almost twice as many coders now as when I first came here.
3) I think this is the difficult part. What the project is all about might not be clear even to the person working on it until it is nearly complete. Until then, it's just a vague idea. Another problem is the big feature creep monster that's lurking in this forum, ready to overwhelm any proposal with usually good, often contradicting, ideas until it suffocates. It can be tempting to keep quiet to avoid attracting its attention.

We don't discourage doing what you propose, it's just that we for whatever reason often don't do it. Reasons might range from seeing it as a pointless wast of time better spent coding, to not wanting the burden of being responsible for a project. There's also the Japanese, who seem to be up to all kinds of stuff, but in a bubble of their own for some reason with little to nothing finding its way back to "our" Simutrans.

Maybe managing Simutrans developers is like herding cats. They come and go as they please, and do whatever they want when they want, for reasons they might not even know themselves.

[Max-Max]

We can never force someone to work in a sertain way, but as we do with the patches, there is a recommended way of announcing them.

If we put up a sticky with a recommended template for projects, just as we have for patches. it is in the end up to the developer(s) to use it or not. What harm can it do?

[Ters]

We can never force someone to work in a sertain way, but as we do with the patches, there is a recommended way of announcing them.

If we put up a sticky with a recommended template for projects, just as we have for patches. it is in the end up to the developer(s) to use it or not. What harm can it do?

I can't think of any. At worst, it will be a small waste of time. Just make sure people understand that it's not mandatory, just encouraged.

[Max-Max]

I guess the sentence "this is not mandatory but a recommendation" will take care of that.

Thinking of how much time people spend to write in the forums, I really don't see why a recommended project template would be a waste of time?

Sometimes it is really good to write down your intentions, because it makes you think about your idea and hopefully it will lead to a better structure from the beginning.

[Max-Max]

I tried out my idea here so you can see what I mean.
No more than this is enough to give people a hint on what's going on.

[isidoro]

[...]
Maybe managing Simutrans developers is like herding cats. They come and go as they please, and do whatever they want when they want, for reasons they might not even know themselves.

Incidentally, I had a male^(*) cat that was just like a dog.  I used to walk him with a leash.  And I used to throw sticks or balls and the cat would bring them back to me.

But I had a strange feeling:  although from the outside it looks exactly the same, when I throw a stick to a dog, I throw it for the animal to bring it back to me.  In the same circumstances, it is the cat that brings the stick for me to throw it away again and again...   
___________________
^(*) well, half male in fact, since he was cut

[jamespetts]

In that case, the cat is the far wiser animal, and we should do well to have more cats and fewer dogs, for their judgment can surely better be trusted.

[Lmallet]

In that case, the cat is the far wiser animal, and we should do well to have more cats and fewer dogs, for their judgment can surely better be trusted.

This reminds me of a sign I saw in one of my neighbour's front window:


Edit:  for those who can't see the image, it says: "Beware of the dog, the cat is not trustworthy either." 

[Ters]

I wonder if the GUI Theme project rather belongs in the Large projects subforum. In fact, all projects big enough to require coordination and a summary might belong there. The world limit project also. Otherwise, I fail to see the purpose of the split.

[kierongreen]

Agreed with the move - any project where the implementation itself is being discussed, there has been substantial progress already, and it is at least considered should be in the larger projects board.

[jamespetts]

Agreed with the move - any project where the implementation itself is being discussed, there has been substantial progress already, and it is at least considered should be in the larger projects board.

That seems sensible.

LMallett - what did the sign say?

[Max-Max]

Did we get anywhere in this matter?
Do you think we can put up a sticky with a recommended project template as the one I made for the Theme project?

[neroden]

I think I disagree a little bit here. Simutrans have some unofficial leaders; the core development team that decides what is and what is not to be included in the main trunk.

As a developer, I want my work to be recognised and as long I don't know if my idea will be included in the main trunk or not, there isn't much point in developing it. Sure I can make a patch but it will break at some point when the trunk moves on...

There is a very subtle point here about development.

If I make a "feature patch", I can maintain it in git forever.  Not a problem.  (There are a few I've kept floating on private git branches, for a long time, since I'm still not sure about them.)

If I make a "cleanup patch" -- something which changes lots of interfaces in order to make things work better -- it *has* to go into the trunk ASAP, or it gets wasted.  Separating "map coords" from "screen coords" is something which will go stale very very quickly.

Accordingly, this sort of coordination is much more important for big structural cleanup work than it is for simple feature changes which are localized to a few files.

Not very many people seem to like to do structural cleanup (is it just me? )

Actually, MaxMax, your GUI project has some elements of that.  The current GUI is assembled by bit-twiddling.  Converting it to use a consistent set of components in a more elegant way is something which really has to be merged when it is ready.  (By contrast, my pretty-cities patch was the sort of thing I could have kept floating in git forever.)

[Ters]

Features being prioritized over cleaning up code seems to be a fact of life. It happens where I work as well, although usually, attempts at cleaning up is blocked before it even starts. I guess it has to do with the fact that while both carry the risk of breaking something, features change the product so that the world can see it, and everybody cheers, whereas clean-ups are effectively only visible to developers, and hence there is less cheering and less understanding if something stops working.

[jamespetts]

From my perspective, as I think that I have commented before, a code restructuring on Experimental alone is a bad idea, since it would make it much harder to merge Standard changes into Experimental in the future.