Developers task list - who does what and when

[martinfst]

It must be my Project Management background, so rest assured I do not want to step on anyones toes ......

I see a lot of motivated contributors / developers for ISPConfig. But the activities seem to be scattered and little alignment is done. Thus, it sometimes happens person A is working on feature B, but that's also impacting Person C working on other elements of feature B. Till has created a short roadmap here, but that mainly focuses on the 2.3 dev branch. For the 2.2 stable branch a lot less is defined, although the majority of effort seems to be put in 2.2 improvements.

As a sidenote: on Sourceforge, I only see a rather old upload of the 2.3.1 branch. I couldn't find a way to get anonymous read access to the SVN, which would show me the contents. In fact, for anonymous readers, the tree structure appears to be empty.

Anyway, I'd like to make the suggestion to create some type of tasklist. See OSCommerce for an example, but Sourceforge also supports tasks. Maybe that can be used? It think it would align our efforts and it would give some kind of insight which feature requests is being worked on and by whom. There are 26 developers allowed to work on this great panel. And I believe 26 individuals could benefit from a bit of guidance

Mind you, I don't want to add timescales to the task list. This is Open Source, right?

Anyone like to comment?

[jnsc]

First of all, I think you are right. A little more organisation would not harm.

As I understand it 2.2 is not ongoing big changements, just bug fixing and updating software to the last release in order to release 2.2.10.

The 2.3.1 is quite old, but alot has changed since this release in svn svn://svn.ispconfig.org/ispconfig/trunk (seems like anonymous read is enabled).

But this is only how I understand this. Till and/or Falko will give you more infos.

[till]

Originally Posted by martinfst

It must be my Project Management background, so rest assured I do not want to step on anyones toes ......

I agree with you, I had this feeling too, thats why I started the roadmap thread. I had started a bug tracking system for ISPconfig some time ago, maybe we can use this also to coordinate our efforts better:

http://www.ispconfig.org/bugtracker/

I will publish the link to the bugtracker also on the development page at ispconfig.org now.

I see a lot of motivated contributors / developers for ISPConfig. But the activities seem to be scattered and little alignment is done. Thus, it sometimes happens person A is working on feature B, but that's also impacting Person C working on other elements of feature B. Till has created a short roadmap here, but that mainly focuses on the 2.3 dev branch. For the 2.2 stable branch a lot less is defined, although the majority of effort seems to be put in 2.2 improvements.

The 2.2.x (stable) branch is currently getting only bugfixes and new versions of the applications delivered with ISPConfig. This is not so much work, thats why I maintain this branch alone at the moment. My goal is to keep the 2.2.x branch as stable as possible so its the first choice for hosting providers using ISPConfig.

All ongoing development with new features is done in the dev branch. There had been many features added the last weeks and some of the modifications where impacting other features so we where not able to release a fully functional dev version for some time. I think we shall focus now for the next weeks to make a new dev release to show all these nice features to the world

As a sidenote: on Sourceforge, I only see a rather old upload of the 2.3.1 branch. I couldn't find a way to get anonymous read access to the SVN, which would show me the contents. In fact, for anonymous readers, the tree structure appears to be empty.

Have you tried this SVN URL:

svn://svn.ispconfig.org/ispconfig/trunk/

Read access should be possible without authentication, I use this e.g. in the scripts that build the nightly SVN builds.

Anyway, I'd like to make the suggestion to create some type of tasklist. See OSCommerce for an example, but Sourceforge also supports tasks. Maybe that can be used? It think it would align our efforts and it would give some kind of insight which feature requests is being worked on and by whom. There are 26 developers allowed to work on this great panel. And I believe 26 individuals could benefit from a bit of guidance

Mind you, I don't want to add timescales to the task list. This is Open Source, right?

Maybe we can use the current bugtracker for this by assigning the requests to developers?

http://www.ispconfig.org/bugtracker/

Personally I like sourceforge as download site very much, but personally I'am not a real fan how their tools work usability wise

What do you think?

[martinfst]

Originally Posted by till

I agree with you, I had this feeling too, thats why I started the roadmap thread. I had started a bug tracking system for ISPconfig some time ago, maybe we can use this also to coordinate our efforts better:

http://www.ispconfig.org/bugtracker/

Great. The tooling doesn't matter much, as long as we have something that's usable. I just checked the url and noticed 25 open bugs, but clicking on the list only revealed 9.

The 2.2.x (stable) branch is currently getting only bugfixes and new versions of the applications delivered with ISPConfig. This is not so much work, thats why I maintain this branch alone at the moment. My goal is to keep the 2.2.x branch as stable as possible so its the first choice for hosting providers using ISPConfig.

Well, I must have missed something then. So all the discussions about converting numbered indexes to associative arrays and making all coding in English is only for the dev branch? What about e.g. the "templates" in /home/admispconfig/....? Also only for 2.3? I think it would help if we were very clear on what's for 2.2 and what's done for 2.3. Will also give a good impression to people who are evaluating ISPConfig.

All ongoing development with new features is done in the dev branch. There had been many features added the last weeks and some of the modifications where impacting other features so we where not able to release a fully functional dev version for some time. I think we shall focus now for the next weeks to make a new dev release to show all these nice features to the world

The 2.3.1-dev tarball on Sourceforge is from May 8, 2006

Have you tried this SVN URL:

svn://svn.ispconfig.org/ispconfig/trunk/

Yeah, tried that this afternoon with a client svn reader. Initially, I was looking for a webinterface to svn, which apparently is not setup. You have such a webreader for SVN of Sourceforge. But this is oke for me and I think is also oke for all developers.

Maybe we can use the current bugtracker for this by assigning the requests to developers?

Sounds good, but we should then start to document every feature that needs work on or where a developer is working on. If we do this administration (I know: boring for real developers, they ha.. it). Now much of the informations is scattered in the forums. Someone should pickup the task to translate forum discussions to bug requests. And developers should report they pick up a request...

Personally I like sourceforge as download site very much, but personally I'am not a real fan how their tools work usability wise

What do you think?

Like every environment there are pro's and con's. I'm involved in another OSS project which uses exclusively Sourceforge tools. Sourceforge is making good improvements recently to their site and tools (slowly, agreed, but compared to a year ago still a lot better). But tooling doesn't matter too much. At least we agree some things can be improved. If that's with the bugtracker you've already setup, let's use that and don't waste time on Yet More New Wheels.

[till]

Originally Posted by martinfst

Great. The tooling doesn't matter much, as long as we have something that's usable. I just checked the url and noticed 25 open bugs, but clicking on the list only revealed 9.

25 Open bugs = 8 unconfirmed (possible) bugs + 1 reopened bug + 12 verified (confirmed) bugs

Its not obvious at the first sight but makes somehow sense i think At least everything is a open bug that is neither fixed nor closed.

Well, I must have missed something then. So all the discussions about converting numbered indexes to associative arrays and making all coding in English is only for the dev branch? What about e.g. the "templates" in /home/admispconfig/....? Also only for 2.3? I think it would help if we were very clear on what's for 2.2 and what's done for 2.3. Will also give a good impression to people who are evaluating ISPConfig.

My intention is:

2.2: only maintenance and bugfixes.
2.3: stabilize the current development, release a few dev releases from this branch very soon and then make the next stable branch out of it.

My Idea behind this is to have always a very stable foundation that we can recommend to everyone who offers hosting solutions. This stable branch is maintained with updates and bugfixes while we develop new features in the dev branch. After some time, we stabilize the dev branch and make the next stable branch with new features out of it and start the development on a new dev branch.

Any suggestions?

The 2.3.1-dev tarball on Sourceforge is from May 8, 2006

Your point

Yeah, tried that this afternoon with a client svn reader. Initially, I was looking for a webinterface to svn, which apparently is not setup. You have such a webreader for SVN of Sourceforge. But this is oke for me and I think is also oke for all developers.

I use only the log in my SVN client, so i did not miss this functionality yet. If you think its needed, I can setup a webinterface for SVN too. Sourceforge did not offer SVN at all at the time we started our SVN repository.

Sounds good, but we should then start to document every feature that needs work on or where a developer is working on. If we do this administration (I know: boring for real developers, they ha.. it). Now much of the informations is scattered in the forums. Someone should pickup the task to translate forum discussions to bug requests. And developers should report they pick up a request...

I've done this already together with Falko. Most of the bugs in the bugtracker are from the forums. Just the faeture requests have still to be added to the bugtracker.

Like every environment there are pro's and con's. I'm involved in another OSS project which uses exclusively Sourceforge tools. Sourceforge is making good improvements recently to their site and tools (slowly, agreed, but compared to a year ago still a lot better).

Yes, I noticed this too. They made a lot of good progress in the last months. I wished they had these features as we started with the project, but at that time they had only CVS.

[alexillsley]

I can help do any graphics / icons if you want me to