FreeOrion

Hello everyone
In short I'm new here and i don't know what to do (programming work). There is some feature request on sf.net tracker however it is outdated, unfortunately. There is road map on wiki however I don't know what has been done - any other tracker? Wiki user story is lacking of necessary details (in some cases eg: http://freeorion.org/index.php/0.4_Desi ... _Detection ).
Btw: there will be nice to have repo access. (geoffthemedio i wanted to send you project join request but i got unknow user response from sf.net mail demon)
and there will be nice to know commit policy.
Anyone using some tracker integrated with eclipse mylyn?

Hi.

A more up-to-date list of programming tasks is the programming work page on the wiki.

I'm not sure what you mean by "user stories". This page that you linked to is the v0.4 design document. The only "user stories" on the wiki are compilation guides.

You don't need any special permission to access the subversion repository. The code can be checked out anonymously, or a tarball can be downloaded.

We don't give commit access to just anyone who wants it. Your first few patches should be posted to the forums for review before someone else (likely me) will commit them.

Don't worry about "joining" the project on sourceforge. We just use sf.net as a bug tracker, subversion host and release file server. If you want to contact someone related to the project, the forums are probably the best way to do so.

Little misunderstanding at start :/

Thx i missed it.


Sure I'm aware of public read only access, however i mean write access.


Can i know why? There is alway possible to revert?


Tracker and source write access

About commit policy:
I mens that if I check in some changes should they compile or maybe they should implement some big task?. I want to know that because i want to do some coding in work and finish it in home. But with no write access to code this is not important i guess.

We don't give commit access to new contributors until they've demonstrated that their code submissions are consistently acceptable. The first few patches anyone submits are reviewed before being committed, and almost always require changes before they're acceptable. Reviewing submission before committing them is easier, avoids polluting the change log with patches and reverts, and doesn't risk interfering with others' work.

Acceptable patches generally need to be doing something that is wanted or needed for the game, well-coded or written or otherwise created, readable and appropriately commented, and compile and run using the CMake build (at least; fixing up the MSVS or XCode projects is also a good idea if possible).

The SVN repository isn't a clipboard to allow one person to copy in-progress code to different locations. To do that, you can make patches to send, or send the whole modified files, to yourself. They're just text, so zip up nicely and aren't too big to attach to an email.