Hi,
This is a proposal for the creation of a new team, the News Team. It is also a call for participation in the same team.
The purpose of this team is to publish news regarding Squeak development and use. It aims to provide a service to the Squeak community, highlighting anything which the Squeak users may find interesting. It will also try to promote Squeak outside its own community, by submitting articles and news items to mainstream websites such as Slashdot and OSNews.
The first task of this team will be publishing The Weekly Squeak. Ideally this news-zine will come to include all the Squeak-related mailing lists, blogs etc. The SqueakViews column will remain under the Weekly Squeak banner, at least initially.
So, if you are either a newcomer or experienced user, and you're interested in joining this team, please speak up and let us know you're available to help!
Thanks,
Giovanni
Giovanni and all,
Here is a first pass at an article for the Weekly Squeak. Let me know what you think.
===================================================
The Foundation is Squeaking.
By Ron Teitelbaum
The Squeak foundation is off and running and already there are major squeaker issues. I guess most of what we see today on squeak-dev@lists.squeakfoundation.org could be considered growing pains. The major issue that arose this week was raised by stéphane ducasse [ducasse@iam.unibe.ch].
The following is all paraphrased. Let me say now that if I got it wrong please feel free to correct me on the list. The benefit of a summary is to highlight ideas, and I hope I was able to do that. Also I hope that if I left some important person or comment out that you will correct that also. Everyone's input is valued.
The problem: There is too much work to do to properly manage the release cycle. There is not enough expertise to do it right. There is not enough development in areas that are buggy because nobody wants to work on some parts of the code.
Solutions:
Stéphane ducasse [ducasse@iam.unibe.ch]: Use the money collected by the foundation to bring commitment, professionalism, and a qualified person to the harvesting area. Also we could fund projects to fix code that people do not have the time or interest to fix.
Göran [goran@krampe.se], Ken Causey [ken@kencausey.com]: Change the structure to allow better access to package owners (stewards and Reviewers). Allow for ownership of packages, email links to owner or group, bug reporting to group, and repository for changes to be posted and made available. Move the coordinating and integration of changes to this new group and let the group be responsible for working with Harvesters to release code. The greater access to groups will help to allow great contribution form general squeakers.
Marcus Denker [denker@iam.unibe.ch]: Changes is good, but real experience is needed to solve real integration problems. Problems can not be ignored and progress can not take forever or people will stop making progress while there changes are being harvested.
Andreas Raab [andreas.raab@gmx.de]: Less control is good, we need to give more of the control to people that actually do the coding. Write access should be allowed to teams (possibly like the Göran and Ken "Steward" model). Changes need to be reviewed and discussed with owners. People should resist the urge to "FIX" someone else's code without discussing it to find out if they even properly understand the code.
Chris Muller [chris@funkyobjects.org]: Images are just that, collections of useful code. It is difficult to get everyone to agree what the one standard configuration should be. We could allow the publishing of working community images and build tools to help integrate from one image to another. By allowing configuration publications, and custom images for custom purposes the images with the most community support will grow, others may not but overall people will pick the best configuration for their need. This removes the need to review and agree on a single image.
Juan Vuletich [jmvsqueak@uolsinectis.com.ar]: Bug fixes yes, major releases no. Major releases should be packaged up and controlled by the developer and released separately and they can be loaded by users that want them.
Michael Rueger [michael@impara.de]: lets stop reinventing and try learning and using the system we have. Mantis is intended to facilitate group discussion and coordination maybe we could write an interface to automatically fill out forms (much like Göran and Ken's changes suggested for bugs and repositories). Let's use the tools we have to help fix the problem.
So where does that leave this problem. I think with some really great progress. The squeaking is loud at times but hopefully it will lead to a better organized and more efficient community group. The struggle over authorship and control, time and energy, stability and innovation, are always problems for every group. It is to everyone credit that change is being discussed, and it should be the responsibility of all to ensure that we make things better. Stef and Marcus should be commended for the hard work and the dedication to this group. Contributions from some very talented people should be acknowledged there would be no squeak without them. This is what a community is all about, we are much more as a group then we could be alone. This is all about helping each other, learning, doing, and having fun.
Ron,
I like the way you condensed the several "disjoint" directions. Also, the title is very, very appropriate and there is not often such a chance for wording something with "squeaking" :)
Wasn't there also Cees De Groot cdegroot@gmail.com who suggested to support as many "disjoint but mergeable" images as the community wants? This might look little OT but I think that Cees should make it into your article.
Besides of that I wouldn't change a single line.
/Klaus
On Thu, 13 Oct 2005 19:15:38 +0200, Ron Teitelbaum Ron@USMedRec.com wrote:
Giovanni and all,
Here is a first pass at an article for the Weekly Squeak. Let me know what you think.
===================================================
The Foundation is Squeaking.
By Ron Teitelbaum
The Squeak foundation is off and running and already there are major squeaker issues. I guess most of what we see today on squeak-dev@lists.squeakfoundation.org could be considered growing pains. The major issue that arose this week was raised by stéphane ducasse [ducasse@iam.unibe.ch].
The following is all paraphrased. Let me say now that if I got it wrong please feel free to correct me on the list. The benefit of a summary is to highlight ideas, and I hope I was able to do that. Also I hope that if I left some important person or comment out that you will correct that also. Everyone's input is valued.
The problem: There is too much work to do to properly manage the release cycle. There is not enough expertise to do it right. There is not enough development in areas that are buggy because nobody wants to work on some parts of the code.
Solutions:
Stéphane ducasse [ducasse@iam.unibe.ch]: Use the money collected by the foundation to bring commitment, professionalism, and a qualified person to the harvesting area. Also we could fund projects to fix code that people do not have the time or interest to fix.
Göran [goran@krampe.se], Ken Causey [ken@kencausey.com]: Change the structure to allow better access to package owners (stewards and Reviewers). Allow for ownership of packages, email links to owner or group, bug reporting to group, and repository for changes to be posted and made available. Move the coordinating and integration of changes to this new group and let the group be responsible for working with Harvesters to release code. The greater access to groups will help to allow great contribution form general squeakers.
Marcus Denker [denker@iam.unibe.ch]: Changes is good, but real experience is needed to solve real integration problems. Problems can not be ignored and progress can not take forever or people will stop making progress while there changes are being harvested.
Andreas Raab [andreas.raab@gmx.de]: Less control is good, we need to give more of the control to people that actually do the coding. Write access should be allowed to teams (possibly like the Göran and Ken "Steward" model). Changes need to be reviewed and discussed with owners. People should resist the urge to "FIX" someone else's code without discussing it to find out if they even properly understand the code.
Chris Muller [chris@funkyobjects.org]: Images are just that, collections of useful code. It is difficult to get everyone to agree what the one standard configuration should be. We could allow the publishing of working community images and build tools to help integrate from one image to another. By allowing configuration publications, and custom images for custom purposes the images with the most community support will grow, others may not but overall people will pick the best configuration for their need. This removes the need to review and agree on a single image.
Juan Vuletich [jmvsqueak@uolsinectis.com.ar]: Bug fixes yes, major releases no. Major releases should be packaged up and controlled by the developer and released separately and they can be loaded by users that want them.
Michael Rueger [michael@impara.de]: lets stop reinventing and try learning and using the system we have. Mantis is intended to facilitate group discussion and coordination maybe we could write an interface to automatically fill out forms (much like Göran and Ken's changes suggested for bugs and repositories). Let's use the tools we have to help fix the problem.
So where does that leave this problem. I think with some really great progress. The squeaking is loud at times but hopefully it will lead to a better organized and more efficient community group. The struggle over authorship and control, time and energy, stability and innovation, are always problems for every group. It is to everyone credit that change is being discussed, and it should be the responsibility of all to ensure that we make things better. Stef and Marcus should be commended for the hard work and the dedication to this group. Contributions from some very talented people should be acknowledged there would be no squeak without them. This is what a community is all about, we are much more as a group then we could be alone. This is all about helping each other, learning, doing, and having fun.
News mailing list News@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/news
The Foundation is Squeaking.
By Ron Teitelbaum
The Squeak foundation is off and running and already there are major squeaker issues. I guess most of what we see today on squeak-dev@lists.squeakfoundation.org could be considered growing pains. The major issue that arose this week was raised by stéphane ducasse [ducasse@iam.unibe.ch].
The following is all paraphrased. Let me say now that if I got it wrong please feel free to correct me on the list. The benefit of a summary is to highlight ideas, and I hope I was able to do that. Also I hope that if I left some important person or comment out that you will correct that also. Everyone's input is valued.
The problem: There is too much work to do to properly manage the release cycle. There is not enough expertise to do it right. There is not enough development in areas that are buggy because nobody wants to work on some parts of the code.
Solutions:
Stéphane ducasse [ducasse@iam.unibe.ch]: Use the money collected by the foundation to bring commitment, professionalism, and a qualified person to the harvesting area. Also we could fund projects to fix code that people do not have the time or interest to fix.
Göran [goran@krampe.se], Ken Causey [ken@kencausey.com]: Change the structure to allow better access to package owners (stewards and Reviewers). Allow for ownership of packages, email links to owner or group, bug reporting to group, and repository for changes to be posted and made available. Move the coordinating and integration of changes to this new group and let the group be responsible for working with Harvesters to release code. The greater access to groups will help to allow great contribution form general squeakers.
Marcus Denker [denker@iam.unibe.ch]: Changes is good, but real experience is needed to solve real integration problems. Problems can not be ignored and progress can not take forever or people will stop making progress while there changes are being harvested.
Andreas Raab [andreas.raab@gmx.de]: Less control is good, we need to give more of the control to people that actually do the coding. Write access should be allowed to teams (possibly like the Göran and Ken "Steward" model). Changes need to be reviewed and discussed with owners. People should resist the urge to "FIX" someone else's code without discussing it to find out if they even properly understand the code.
Chris Muller [chris@funkyobjects.org]: Images are just that, collections of useful code. It is difficult to get everyone to agree what the one standard configuration should be. We could allow the publishing of working community images and build tools to help integrate from one image to another. By allowing configuration publications and custom images for custom purposes the images with the most community support will grow, others may not but overall people will pick the best configuration for their need. This removes the need to review and agree on a single image.
Cees De Groot [cdegroot@gmail.com]: Supported the idea that there should be as many "disjoint but mergeable" images as the community wants. There should be less effort into coming up with a single image. By focusing on packages we allow better integration between images, and more configuration options.
Juan Vuletich [jmvsqueak@uolsinectis.com.ar]: Bug fixes yes, major releases no. Major releases should be packaged up and controlled by the developer and released separately and they can be loaded by users that want them.
Michael Rueger [michael@impara.de]: lets stop reinventing and try learning and using the system we have. Mantis is intended to facilitate group discussion and coordination maybe we could write an interface to automatically fill out forms (much like Göran and Ken's changes suggested for bugs and repositories). Let's use the tools we have to help fix the problem.
So where does that leave this problem. I think with some really great progress. The squeaking is loud at times but hopefully it will lead to a better organized and more efficient community group. The struggle over authorship and control, time and energy, stability and innovation, are always problems for every group. It is to everyone credit that change is being discussed, and it should be the responsibility of all to ensure that we make things better. Stef and Marcus should be commended for the hard work and the dedication to this group. Contributions from some very talented people should be acknowledged there would be no squeak without them. This is what a community is all about, we are much more as a group then we could be alone. This is all about helping each other, learning, doing, and having fun.
-----Original Message----- From: Klaus D. Witzel [mailto:klaus.witzel@cobss.com] Sent: Thursday, October 13, 2005 1:44 PM To: Ron@usmedrec.com; The mailing list for the Squeak News Team; 'Giovanni Corriga' Subject: Re: [News] Weekly Squeak Article
Ron,
I like the way you condensed the several "disjoint" directions. Also, the title is very, very appropriate and there is not often such a chance for wording something with "squeaking" :)
Wasn't there also Cees De Groot cdegroot@gmail.com who suggested to support as many "disjoint but mergeable" images as the community wants? This might look little OT but I think that Cees should make it into your article.
Besides of that I wouldn't change a single line.
/Klaus
On Thu, 13 Oct 2005 19:15:38 +0200, Ron Teitelbaum Ron@USMedRec.com wrote:
Giovanni and all,
Here is a first pass at an article for the Weekly Squeak. Let me know what you think.
===================================================
The Foundation is Squeaking.
By Ron Teitelbaum
The Squeak foundation is off and running and already there are major squeaker issues. I guess most of what we see today on squeak-dev@lists.squeakfoundation.org could be considered growing pains. The major issue that arose this week was raised by stéphane ducasse [ducasse@iam.unibe.ch].
The following is all paraphrased. Let me say now that if I got it wrong please feel free to correct me on the list. The benefit of a summary is to highlight ideas, and I hope I was able to do that. Also I hope that if I left some important person or comment out that you will correct that also. Everyone's input is valued.
The problem: There is too much work to do to properly manage the release cycle. There is not enough expertise to do it right. There is not enough development in areas that are buggy because nobody wants to work on some parts of the code.
Solutions:
Stéphane ducasse [ducasse@iam.unibe.ch]: Use the money collected by the foundation to bring commitment, professionalism, and a qualified person to the harvesting area. Also we could fund projects to fix code that people do not have the time or interest to fix.
Göran [goran@krampe.se], Ken Causey [ken@kencausey.com]: Change the structure to allow better access to package owners (stewards and Reviewers). Allow for ownership of packages, email links to owner or group, bug reporting to group, and repository for changes to be posted and made available. Move the coordinating and integration of changes to this new group and let the group be responsible for working with Harvesters to release code. The greater access to groups will help to allow great contribution form general squeakers.
Marcus Denker [denker@iam.unibe.ch]: Changes is good, but real experience is needed to solve real integration problems. Problems can not be ignored and progress can not take forever or people will stop making progress while there changes are being harvested.
Andreas Raab [andreas.raab@gmx.de]: Less control is good, we need to give more of the control to people that actually do the coding. Write access should be allowed to teams (possibly like the Göran and Ken "Steward" model). Changes need to be reviewed and discussed with owners. People should resist the urge to "FIX" someone else's code without discussing it to find out if they even properly understand the code.
Chris Muller [chris@funkyobjects.org]: Images are just that, collections of useful code. It is difficult to get everyone to agree what the one standard configuration should be. We could allow the publishing of working community images and build tools to help integrate from one image to another. By allowing configuration publications, and custom images for custom purposes the images with the most community support will grow, others may not but overall people will pick the best configuration for their need. This removes the need to review and agree on a single image.
Juan Vuletich [jmvsqueak@uolsinectis.com.ar]: Bug fixes yes, major releases no. Major releases should be packaged up and controlled by the developer and released separately and they can be loaded by users that want them.
Michael Rueger [michael@impara.de]: lets stop reinventing and try learning and using the system we have. Mantis is intended to facilitate group discussion and coordination maybe we could write an interface to automatically fill out forms (much like Göran and Ken's changes suggested for bugs and repositories). Let's use the tools we have to help fix the problem.
So where does that leave this problem. I think with some really great progress. The squeaking is loud at times but hopefully it will lead to a better organized and more efficient community group. The struggle over authorship and control, time and energy, stability and innovation, are always problems for every group. It is to everyone credit that change is being discussed, and it should be the responsibility of all to ensure that we make things better. Stef and Marcus should be commended for the hard work and the dedication to this group. Contributions from some very talented people should be acknowledged there would be no squeak without them. This is what a community is all about, we are much more as a group then we could be alone. This is all about helping each other, learning, doing, and having fun.
News mailing list News@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/news
news@lists.squeakfoundation.org