I don't know much about TortoiseSVN. I tried using it briefly, then decided that I preferred using SVN from the command line. One advantage of the latter is that there's comprehensive documentation (the SVN book).
But TortoiseSVN is widely used, so it probably has equivalent functionality and documentation.
My first reaction is: don't make the same mistake I did, and the one that DJ made a thousandfold bigger: organize to get organized.
Teams are a very nice concept, but they have only temporary value. No team I have seen (and I have seen a LOT of teams!) has the stamina to keep working for more then a few months, and that is when it is working at all.
I propose to skip the roll call and name listing games and go right to the heart of the matter: projects.
In stead of creating teams who are responsible for certain sets of tasks (which implicitly means you're excusing everyone else to feel any responsibility for this work!), create projects to get a specific result in a specific way. Then, teams can be formed around these projects, but they'd be temporary and focused. Appoint one project lead who gets the task of making sure that the project is in sync with the rest, and you've got yourself a manageable structure where open collaboration is the standard.
Anyone can start a project, and ask for support from something that manages the assets.
My first reaction was '3 months is too short'. The reason being it adds extra time just to reset and make transitions between the 'top man/woman'. Transitions are always unproductive.
I know the intent is to keep the potential for disaster while a particular person is in that seat, but for someone intent on doing things their way, it only takes a matter of weeks to foul things up.
My second reaction was to hold off until the draft proposal has more definition. It has some good principles and if we appear to be acting without consideration for their efforts, our credibility is at risk.
The task groups in this proposal are very close to what the proposal team is moving forward. And that is a good thing, because it deals with the actual work that needs to be done and applying the resources where needed.
A lot is happening and I feel a bit lost at times. A clear vision, as Herko was saying, is definitely higher on the list of things to be done for me.
Actual work processes (ooh, I hate that I just said that) need to be established, because they are not evident in the current XOOPS environment - security reviews and audits, code review and comment, feature/functionality/benefit analysis, testing and quality assurance, transparency and integrity are all major items.
One thing we need to keep in the front of our minds at all times - we judge ourselves by our intentions, others judge us by our actions.
Hi saganxis and welcome here !
Have a read of these forums and start implicating yourself. And tel us know if you have any questions.
Nice to have you here !
I agree with this - if I had posted that I was working on the system templates, it would have eliminated a conflict that arose when the latest 2.0.18rc changes were committed.
Let's give it a start
Please note: This is only a proposal at the moment - but I am hoping that you will think it of merit to consider.
We have been very privildged to have some extremely skilled people getting involved in this project.
However in the fast paced development of the new core, it's becoming more obvious that we need to start the groundwork on internal teams to manage the different areas of our project.
So far - several people have stepped up to help in different areas ourside of their ususal ones - and I feel that even with "organised teams" - this still is not a bad thing.
So: what teams do we need to work on?
Essentially we need to gather together:
Core Team: We've a large group of talented developers at the moment - and I feel this number could easily rise.
(BTW: I would suggest that anyone who hasn't done so, perhaps completes their "skills" in Sourceforge?)
I'm unsure of exactly the best requirements of this team myself - but I'm sure someone more knowledgable can add this?
Communications, Documentation & Promotions Team:
These would include people to help relay news from the project development, assist in the production of documentation, and with the promotion of the project.
This team would also include members who can assist with the Wiki site.
Community Forum Moderators:
People willing to assist in the community forum. Trusted members would also have the relevent authority to deal with troublemakers.
Module/Theme Repository Team:
Initially just would be needed to ensure modules are uploaded and categoried correctly. However, this team would evolve later to improve classification and quality control testing.
Site Maintainance Team:
At the current time - responsible for the planning and installation of the new site.
At a later stage, this team would be partly responsible for general maintainance - but also work with other teams in improving the sites.
* * * * * * * * *
Gradually we will need to expand and change these teams, as fits a growing project - and depending on the teams requirements. But for the moment, if we start on the essential parts - we will at least have something practical to build from.
* * * * * * * * *
I can see a need for the following areas to be covered:
Translations: core translations
Module Development: an alternative to dev.xoops - I would perhap make the suggestion that we use a seperate sourceforge site - with seperate forums available?
Akitson has done some groundwork on this with his xoopsmoddev.org site - perhaps he would be willing to assist in such a team?
This could also include Module Security testing, as well as Quality testing as well. (Perhaps a certification program?)
Any feedback on this would be appreciated.
* * * * * * *
We are aware from personal experience, that having inflexible management structure is not a good thing.
I have been examing many ideas recently - and have discussed the pros and cons with several people - and I feel the simplest methods the best:
1) Each team has 1 "top man" (manager, team leader, whatever you wish to call the title) - who is chosen from within the team by voting.
This "top man" will serve for a period of 3 months.
At the end of this time, another "top man" is chosen - or if the team wishes, the same person can stand again.
2) Each of the "top men" will form a team - which will act as the co-ordinators for us all.
Again - their position will only last for 3 months - or less if situations require it.
3) We don't have an overall "leader" - we have elected people from the ranks - who have to contribute their best.
In order to better document and follow up the changes we do in our SVN, what do you think about the following.
Before coding something new of fixing a bug, we add an item either in the bug tracker, or the feature tracker, or for larger things, in the task tracker.
Then we code it, commit it, and make sure to link our SVN commit message with the ID of the item we created.
That way, changes will truly be documented and opened for commenting by other developer which is a very good thing.
For example, yesterday, I added the multilanguage feature. I did not add an item in the tracker. So today I found out 2 things.
1- Rodriguo already did something similar in Xoopers.
2- I forgot to change the install process to add the new config options in the databse, same thing for the upgrade script.
If I had added a task or feature requesy at SF for this, may Rodriguo could have told me he already did it, and david and nekro could have documented that it was not working.
I'm going to add a task for the ML now
And I understand now. Vaughan added the "exit;" in the original mainfile.php :
Hi guys, I just updated sandbox of the trunk and nothing is working no more. Just blank page, no debug. I will look into it but if anyone has an idea, please join me in the ImpressCMS IRC Channel, which, by the way, I implore all dev to try and use as much as possible. Will make it easier to help each other.