Smalltalk › Squeak › Squeak - Dev

SqF feedback

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

stéphane ducasse-2

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

Daniel Vainsencher-2

Re: SqF feedback

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
>
>
>

stéphane ducasse-2

Re: SqF feedback

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
>>
>>
>>
>
>

Ron Teitelbaum

RE: SqF feedback

In reply to this post by stéphane ducasse-2

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
[hidden email]
Squeak Cryptography Team Leader
Squeak News Team Member

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] 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
>
>
>

Marcus Denker

Re: SqF feedback

On 03.03.2006, at 20:01, Ron Teitelbaum wrote:

Good List!

>
> 1) Squeak Foundation Legal Entity Formation
> 2) 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

Peter Crowther-2

RE: SqF feedback

In reply to this post by stéphane ducasse-2

> From: stéphane ducasse
> if you have some points that you would like to see happening
> please mention it.

Decide what, if anything, SqF wishes to do about the de-facto fragmentation of Squeak into different communities. I'm not sure how much of a mandate there is for this - I ran for the board based on wanting to reduce the fragmentation, and I came soundly last :-).

Investigate what, if anything, that fragmentation has to do with the two Achilles heels of image-based development, namely me getting functionality that I want into my image and me removing functionality that I don't want from my image.

- Peter

Brad Fuller

Re: SqF feedback

In reply to this post by stéphane ducasse-2

stéphane ducasse wrote:

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.

signature.asc (196 bytes) Download Attachment

Lukas Renggli

Re: SqF feedback

> 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.

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

Philippe Marschall

Re: SqF feedback

In reply to this post by Daniel Vainsencher-2

2006/3/3, Daniel Vainsencher <[hidden email]>:

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
> >
> >
> >
>
>
>

ccrraaiigg

Re: SqF feedback

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)]

Lukas Renggli

Re: SqF feedback

In reply to this post by Philippe Marschall

> > - 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

--
Lukas Renggli
http://www.lukas-renggli.ch

Lex Spoon-3

Re: SqF feedback

In reply to this post by ccrraaiigg

Craig Latta <[hidden email]> 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