Hi
I'm reposting this email since I have the impression that the point was lost in its original thread.
... - Normally after election, politicians do not really listen anymore and I would like to do the inverse. I would really like to know what you expect or would like to see put in place. We have some ideas (bounty system, better process) and I will really listen what the new boarders want to do (I'm even eager to see that :)).
We do not have the monopole of good ideas, so if you have some points that you would like to see happening please mention it.
Stef
A. More ties with sibling communities: - news about their progress, - guides and up to date pointers to their releases (see the recent "which Squeakland should I use for..." discussion) and so forth. - More visibility for the processes of code synchronization between us and them (some way people can quickly answer the question - what are we missing compared to <your favorite variant of squeak). - More cross project "platform" discussion, to share opinions (and maybe even coordinate policy) about various changes to Squeak as a platform. Examples: adoption of ToolBuilder, Traits, OB vs traditional browser, annotations, Flow... B. Action on the license front - a decision on a license policy. Since we're on the "what I'd like to see" - I think we should try to lower the percent of non-freely licensed code in the image: - request that new packages be at least dual licensed MIT, - Find out some conservative approximation of "who holds what copyrights", and relicense to MIT anything we can get consent for. - Encourage people that are changing packages significantly (refactoring collections to use traits) to rewrite instead, and place it under a free license. - have SqueakSource repositories have a "if you upload code here, by default it is under license ..." field per project, to make . C. Continue improving Squeak governance - we now have an elected board, which is better than the previous modes of selection. However, the relation of this board to various aspects of Squeak is unclear: - Who decides whether to push <your favorite disruptive change> into the current version? - Relation to non-package-maintaining teams: who decides membership and scope of a team? The important thing here is that we evolve/design the structure, so that it improves over time, rather than the sometimes arbitrary-seeming changes we've had in the past.
Daniel
stéphane ducasse wrote:
Hi
I'm reposting this email since I have the impression that the point was lost in its original thread.
... - Normally after election, politicians do not really listen anymore and I would like to do the inverse. I would really like to know what you expect or would like to see put in place. We have some ideas (bounty system, better process) and I will really listen what the new boarders want to do (I'm even eager to see that :)).
We do not have the monopole of good ideas, so if you have some points that you would like to see happening please mention it.
Stef
Tx! This is a good list.
Stef
On 3 mars 06, at 12:22, Daniel Vainsencher wrote:
A. More ties with sibling communities:
- news about their progress,
- guides and up to date pointers to their releases (see the recent
"which Squeakland should I use for..." discussion) and so forth.
- More visibility for the processes of code synchronization between
us and them (some way people can quickly answer the question - what are we missing compared to <your favorite variant of squeak).
- More cross project "platform" discussion, to share opinions (and
maybe even coordinate policy) about various changes to Squeak as a platform. Examples: adoption of ToolBuilder, Traits, OB vs traditional browser, annotations, Flow... B. Action on the license front - a decision on a license policy. Since we're on the "what I'd like to see" - I think we should try to lower the percent of non-freely licensed code in the image:
- request that new packages be at least dual licensed MIT,
- Find out some conservative approximation of "who holds what
copyrights", and relicense to MIT anything we can get consent for.
- Encourage people that are changing packages significantly
(refactoring collections to use traits) to rewrite instead, and place it under a free license.
- have SqueakSource repositories have a "if you upload code here,
by default it is under license ..." field per project, to make . C. Continue improving Squeak governance - we now have an elected board, which is better than the previous modes of selection. However, the relation of this board to various aspects of Squeak is unclear:
- Who decides whether to push <your favorite disruptive change>
into the current version?
- Relation to non-package-maintaining teams: who decides membership
and scope of a team? The important thing here is that we evolve/design the structure, so that it improves over time, rather than the sometimes arbitrary- seeming changes we've had in the past.
Daniel
stéphane ducasse wrote:
Hi
I'm reposting this email since I have the impression that the point was lost in its original thread.
... - Normally after election, politicians do not really listen anymore and I would like to do the inverse. I would really like to know what you expect or would like to see put in place. We have some ideas (bounty system, better process) and I will really listen what the new boarders want to do (I'm even eager to see that :)).
We do not have the monopole of good ideas, so if you have some points that you would like to see happening please mention it.
Stef
2006/3/3, Daniel Vainsencher danielv@techunix.technion.ac.il:
A. More ties with sibling communities:
- news about their progress,
- guides and up to date pointers to their releases (see the recent
"which Squeakland should I use for..." discussion) and so forth.
- More visibility for the processes of code synchronization between us
and them (some way people can quickly answer the question - what are we missing compared to <your favorite variant of squeak).
- More cross project "platform" discussion, to share opinions (and maybe
even coordinate policy) about various changes to Squeak as a platform. Examples: adoption of ToolBuilder, Traits, OB vs traditional browser, annotations, Flow... B. Action on the license front - a decision on a license policy. Since we're on the "what I'd like to see" - I think we should try to lower the percent of non-freely licensed code in the image:
- request that new packages be at least dual licensed MIT,
- Find out some conservative approximation of "who holds what
copyrights", and relicense to MIT anything we can get consent for.
- Encourage people that are changing packages significantly (refactoring
collections to use traits) to rewrite instead, and place it under a free license.
- have SqueakSource repositories have a "if you upload code here, by
default it is under license ..." field per project, to make .
Implemented. Waiting for review and deployment if accepted.
Philippe
C. Continue improving Squeak governance - we now have an elected board, which is better than the previous modes of selection. However, the relation of this board to various aspects of Squeak is unclear:
- Who decides whether to push <your favorite disruptive change> into the
current version?
- Relation to non-package-maintaining teams: who decides membership and
scope of a team? The important thing here is that we evolve/design the structure, so that it improves over time, rather than the sometimes arbitrary-seeming changes we've had in the past.
Daniel
stéphane ducasse wrote:
Hi
I'm reposting this email since I have the impression that the point was lost in its original thread.
... - Normally after election, politicians do not really listen anymore and I would like to do the inverse. I would really like to know what you expect or would like to see put in place. We have some ideas (bounty system, better process) and I will really listen what the new boarders want to do (I'm even eager to see that :)).
We do not have the monopole of good ideas, so if you have some points that you would like to see happening please mention it.
Stef
Hi Daniel--
B. Action on the license front - a decision on a license policy.
I thought we made that decision last year, to move to an MIT-style license (see [1]). Please let me know if there's something missing from there.
Who decides whether to push <your favorite disruptive change> into the current version?
The release team decides that. The release team is appointed by the board, and the release team's decisions are subject to the approval of the board. We think this is appropriate, given our election.
Relation to non-package-maintaining teams: who decides membership and scope of a team?
So far, we've simply encouraged people to start teams, by leading them. The team leaders then get to solicit volunteers for their teams, and hand off leadership as necessary. We haven't thought of anything that works better than that, but we're always open to suggestions.
thanks,
-C
[1] http://netjam.org/squeak/contributors
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
Craig Latta craig@netjam.org writes:
Who decides whether to push <your favorite disruptive change> into the current version?
The release team decides that. The release team is appointed by the
board, and the release team's decisions are subject to the approval of the board. We think this is appropriate, given our election.
[...]
So far, we've simply encouraged people to start teams, by leading
them. The team leaders then get to solicit volunteers for their teams, and hand off leadership as necessary. We haven't thought of anything that works better than that, but we're always open to suggestions.
That all sounds great, and it seems to have worked well in practice. Now all we need are even more cool Squeak-based teams and projects.
Lex
- have SqueakSource repositories have a "if you upload code here, by
default it is under license ..." field per project, to make .
Implemented. Waiting for review and deployment if accepted.
It is deployed on www.squeaksource.com
Lukas
Stef,
1) Squeak Foundation Legal Entity Formation 2) Stabilization of current implementation 3.9a including focusing on issues that separate Squeak, SqueakLand, wxSqueak, Tweak, Croquet, Seaside and Spoon, and actively support and promote all. 3) Focus on issues that remain with Traits. 4) Work on and identify issues that prevent the business community from adopting squeak. 5) Produce a better framework for attracting web development, including courting existing large Hosting companies to support squeak and offer it for end user applications, and developing web frameworks control panels that automatically integrate and install developed applications, to encourage larger adoption of squeak. Also developing end user applications, integration with control panels, and demo sites for each, all in a single easy find location. 6) Support the efforts of the cryptography group as we develop cryptography frameworks, including the financial support for the Cryptographic Module Validation Program (CMVP) through the OpenSSL Federal Information Processing Standard (FIPS) Certification Process which we believe will go a long way to encourage business to adopt Squeak. 7) Complete the network integration of Flow, and begin supporting more business protocols: ASN.1, XL7, NCPDP, X.12, EDI ...
I think we can complete these goals this year and move on to more next year! (including working on license issues)
Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron@USMedRec.com Squeak Cryptography Team Leader Squeak News Team Member
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of stéphane ducasse Sent: Thursday, March 02, 2006 4:01 PM To: The general-purpose Squeak developers list Subject: SqF feedback
Hi
I'm reposting this email since I have the impression that the point was lost in its original thread.
...
- Normally after election, politicians do not really listen anymore
and I would like to do the inverse. I would really like to know what you expect or would like to see put in place. We have some ideas (bounty system, better process) and I will really listen what the new boarders want to do (I'm even eager to see that :)).
We do not have the monopole of good ideas, so if you have some points that you would like to see happening please mention it.
Stef
On 03.03.2006, at 20:01, Ron Teitelbaum wrote:
Good List!
- Squeak Foundation Legal Entity Formation
- Stabilization of current implementation 3.9a
We are commited to go beta as soon as possible. On the list are -> sync with SqueakLand -> sync with SmallLand -> sync with IO-Team -> update SqueakMap -> fix the Traits bug -> ... some smaller things ... (e.g. another pass over all mantis reports)
After that, we should go beta.
Marcus
stéphane ducasse wrote:
Hi
I'm reposting this email since I have the impression that the point was lost in its original thread.
... - Normally after election, politicians do not really listen anymore and I would like to do the inverse. I would really like to know what you expect or would like to see put in place. We have some ideas (bounty system, better process) and I will really listen what the new boarders want to do (I'm even eager to see that :)).
We do not have the monopole of good ideas, so if you have some points that you would like to see happening please mention it.
1) MULTIMEDIA AUTHORING I personally would like to see an effort to make Squeak better in the multimedia area - especially audio. The base audio functionality needs major overhaul. And, the audio apps are really old and reflect a technology that isn't up to today's standards. Not that it isn't, mind you. It just looks that way.
Unfortunately, I think it's a catch 22 situation. While many agree that the audio capability needs improvement, many in the dev-list are busy with other issues. There aren't a lot of people like me that are "composers" or "audio people". And since, we don't bring in the people that would like to use squeak as a multimedia development and authoring platform, there's no development need. But, I think Squeak has great promise for multimedia authors if we focus on improving the basics (which is what I'm currently doing by myself).
2) MULTIMEDIA WEB I'm having loads of fun with Seaside, and I'd like to see a push to provide improvements for multimedia web deployments.
- MULTIMEDIA WEB
I'm having loads of fun with Seaside, and I'd like to see a push to provide improvements for multimedia web deployments.
See my latest commits into the Scriptaculous package http://www.squeaksource.com/Seaside/. It supports a bunch of new effects, drag&drop, etc. Also have a look at the packages of Philippe http://www.squeaksource.com/seachart.html .
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
squeak-dev@lists.squeakfoundation.org