Re: Scala Community Petition

Sounds like a great plan. I know I'd definitely have my own fork once
the move is completed.

On Thu, Jun 9, 2011 at 5:32 PM, Yuvi Masory wrote:
> I personally think 3 & 2 above are the most urgent, in that order.
> Regarding documentation, I have a few thoughts.
> - Somehow the internal traits and methods need to be hidden. I know this is
> a very difficult problem in Scala, and I have no idea how to solve it. I
> just feel we are in need of some method of supressing clutter in the docs.
> - I feel there needs to be more documentation, period.
> - I feel the docs would benefit from examples, like some of the Java API
> docs have.
> - Regarding the UI, great great progress has been made. (Especially the new
> more-conspicuous companion class "button"). However, it drives me nuts that
> the return types aren't aligned like javadocs. Most of the time I know the
> return type of the method I'm looking for and would like visually search
> based on that.
> With respect to there simply not being enough documentation I organized the
> Friday documentation spree at Scalathon. We will have 30 brand new
> contributors working on the docs all day. Hopefully we will smooth over the
> procedural rough spots and make some lasting contributors. But the biggest
> step forward would be to pay more attention to GitHub. The fork & pull model
> makes it dead simple to contribute documentation. The main trouble (I think)
> is that first, no one is *asking* random people in the community to fork &
> commit API docs, and second, only Paul Philips is merging in pull requests.
> A complete move to GitHub (or at least more attention to GitHub) would make
> it much easier to contribute documentation until Colladoc is ready for prime
> time.
>
> Yuvi
>
>
>
> On Thu, Jun 9, 2011 at 5:26 PM, Michael Cotterell
> wrote:
>>
>> Touche...
>>
>> Also, to begin: Concerning "Documentation of the core libs needs to be
>> treated at least as seriously as the code.", I believe this is vital.
>> When I open up the ScalaDoc for Scala itself, I shouldn't see any
>> methods that are undocumented. I can deal with the implementation
>> being undocumented, but the API documentation should be thorough.
>>
>> On Thu, Jun 9, 2011 at 5:22 PM, Yuvi Masory wrote:
>> > I wanted to forum instead of the mailing list mostly for UI reasons.
>> > It's easy for things to be lost in the fold in a mailing list. Plus the
>> > moderator page counts votes which is much needed for this to be
>> > democratic.
>> > That said, I'd love it if some of the suggestions were discussed on the
>> > mailing list. (Since email is a pretty good UI for discussing).
>> > The top 3 at the moment are:
>> > 1) "The SBT move should be completed."
>> > 2) "Documentation of the core libs needs to be treated at least as
>> > seriously
>> > as the code."
>> > 3) "The GitHub move should be completed."
>> >
>> > Yuvi
>> >
>> >
>> >
>> > On Thu, Jun 9, 2011 at 5:13 PM, Michael Cotterell
>> >
>> > wrote:
>> >>
>> >> Why the forum and not the mailing list?
>> >>
>> >> Sincerely,
>> >> Michael Cotterell
>> >> mepcotterell@gmail.com
>> >> mepcott@uga.edu
>> >>
>> >> P.S. - Check out ScalaTion (http://code.google.com/p/scalation/), a
>> >> Domain-Specific Language for Modeling & Simulation.
>> >
>> >
>>
>>
>>
>> --
>> Sincerely,
>> Michael Cotterell
>> mepcotterell@gmail.com
>> mepcott@uga.edu
>>
>> P.S. - Check out ScalaTion (http://code.google.com/p/scalation/), a
>> Domain-Specific Language for Modeling & Simulation. #blatantplug
>
>

Holy crap! Progress on the GitHub move:
https://github.com/scala/scala/wiki/Github-Move
Thanks Daniel for pointing this out on Twitter.

Yuvi

Hi Yuvi, all.

Thanks for this survey, it is really very useful for prioritizing things. Now we need volunteers to actually do the things that were demanded. We have some new people coming in at EPFL and there will be some reshuffling, so we might be able to find volunteers internally for some of the things that were mentioned. We'll discuss the survey at one of the next Scala meetings. It's not going to be easy, precisely because Scala popularity is increasing rapidly and there are a lot of interactions with people in the community to be had. This is fundamentally a good thing. But it can also take a big toll from a graduate student, who's first task is to publish papers and get his or her thesis finished.  We'll also try to do what we can on the Typesafe side, but again, resources are limited.

In summary we'll have to figure out how to do all this (because all the points raised in the survey are worth doing). Any help from the community would be greatly appreciated, and will in fact be essential.

We'll discuss and figure out a way to involve the community.

Best,

 -- Martin

----------------------------------------------
Martin Odersky
Prof., EPFL and CEO, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

Martin, et el.,
With all due respect but how come screaming-in-your-face
"Documentation of the core libs needs to be treated at least as
seriously as the code" should require a **volunteer** work of some
helpless grad when you got funded $3M just few months ago?

It may not be the sexiest part of work but that's exactly what Scala
eco-system is badly missing right now - the true commercial quality of
software engineering that starts right from basic documentation. This
is a not side gig anymore and not a pet project - we, as a community,
are really trying to push it beyond early adopters. And this type of
attitude is exactly what drives away my enterprise customers from
Scala despite my strong push to promote it - "effort of some
volunteers...". Yeah - tell that line to someone from BofA.

It's a bit of a venting off - granted. But I am really hoping that
Typesafe will finally help Scala graduate from an academic project to
the real world. Wasn't the reason for it to being with?

Best,
--
Nikita Ivanov
GridGain Systems.

On Jun 12, 4:17 pm, martin odersky wrote:
> Hi Yuvi, all.
>
> Thanks for this survey, it is really very useful for prioritizing things.
> Now we need volunteers to actually do the things that were demanded. We have
> some new people coming in at EPFL and there will be some reshuffling, so we
> might be able to find volunteers internally for some of the things that were
> mentioned. We'll discuss the survey at one of the next Scala meetings. It's
> not going to be easy, precisely because Scala popularity is increasing
> rapidly and there are a lot of interactions with people in the community to
> be had. This is fundamentally a good thing. But it can also take a big toll
> from a graduate student, who's first task is to publish papers and get his
> or her thesis finished.  We'll also try to do what we can on the Typesafe
> side, but again, resources are limited.
>
> In summary we'll have to figure out how to do all this (because all the
> points raised in the survey are worth doing). Any help from the community
> would be greatly appreciated, and will in fact be essential.
>
> We'll discuss and figure out a way to involve the community.
>
> Best,
>
>  -- Martin
>
> ----------------------------------------------
> Martin Odersky
> Prof., EPFL and CEO, Typesafe
> PSED, 1015 Lausanne, Switzerland
> Tel. EPFL: +41 21 693 6863
> Tel. Typesafe: +41 21 691 4967

Hi Martin,

I'm glad things are moving forward. However, I'm pretty skeptical
things will move forward unless there is someone with the time and the
interest to *manage* contributions. Paul is the closest we have to a
manager at the moment, but he's busy and by his own admission more
interested in writing code of his own.
We need a community liaison. Someone to answer questions, merge
trivial pull requests (e.g., documentation), review other patches,
coordinate volunteers, invite participation, etc, etc.
We could have an army of volunteers (actually, I think we already do),
but with the current structure of knowledge and permissions it's
impossible for a volunteer to do anything other than get discouraged.

Yuvi

On Sun, Jun 12, 2011 at 7:17 PM, martin odersky wrote:
> Hi Yuvi, all.
>
> Thanks for this survey, it is really very useful for prioritizing things.
> Now we need volunteers to actually do the things that were demanded. We have
> some new people coming in at EPFL and there will be some reshuffling, so we
> might be able to find volunteers internally for some of the things that were
> mentioned. We'll discuss the survey at one of the next Scala meetings. It's
> not going to be easy, precisely because Scala popularity is increasing
> rapidly and there are a lot of interactions with people in the community to
> be had. This is fundamentally a good thing. But it can also take a big toll
> from a graduate student, who's first task is to publish papers and get his
> or her thesis finished.  We'll also try to do what we can on the Typesafe
> side, but again, resources are limited.
>
> In summary we'll have to figure out how to do all this (because all the
> points raised in the survey are worth doing). Any help from the community
> would be greatly appreciated, and will in fact be essential.
>
> We'll discuss and figure out a way to involve the community.
>
> Best,
>
>  -- Martin
>
> ----------------------------------------------
> Martin Odersky
> Prof., EPFL and CEO, Typesafe
> PSED, 1015 Lausanne, Switzerland
> Tel. EPFL: +41 21 693 6863
> Tel. Typesafe: +41 21 691 4967
>
>

> It may not be the sexiest part of work but that's exactly what Scala
> eco-system is badly missing right now - the true commercial quality of
> software engineering that starts right from basic documentation.

I think writing documentation is sexy, but why would I even bother if
it will never get merged in?

Yuvi

I would like to second that sentiment. I like writing documentation after I have unearthed some undocumented details. The last time I tried it, the documentation never made it into the code base. I got the impression that documentation is not valued.

-----Original Message-----
From: scala-language@googlegroups.com [mailto:scala-language@googlegroups.com] On Behalf Of Yuvi Masory
Sent: Monday, June 13, 2011 1:22 PM
To: scala-language@googlegroups.com
Subject: Re: [scala-language] Re: Scala Community Petition

> It may not be the sexiest part of work but that's exactly what Scala
> eco-system is badly missing right now - the true commercial quality of
> software engineering that starts right from basic documentation.

I think writing documentation is sexy, but why would I even bother if
it will never get merged in?

Yuvi

________________________________

This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).

It seems self-evident that bad documentation is worse than no documentation (or at least equivalently bad). Hence someone would have to painstakingly check your documentation and in particular any examples contained therein for correctness. As it's a reasonable assumption that the lack of documentation in the first place (which, in any case, is these days is not as much of a problem as it once was) is down to the available time of the scala committers, it follows that there's a good chance they won't have time to check any documentation which is "externally" provided.
Chris

On Mon, Jun 13, 2011 at 6:22 PM, Yuvi Masory <ymasory@gmail.com> wrote:

> It may not be the sexiest part of work but that's exactly what Scala
> eco-system is badly missing right now - the true commercial quality of
> software engineering that starts right from basic documentation.

I think writing documentation is sexy, but why would I even bother if
it will never get merged in?

Yuvi

This is where the beauty of something like colladoc becomes evident.  It's not just about crowd-sourcing the authoring, it's about crowd-sourcing the editing, checking, revision and final approval.
We all appreciate the fact that the core committers are busy, and we appreciate the things that they're bust working on.  However, we can't just end the discussion there and accept a lack of documentation for the indefinite future.  We need to find a way to make this happen with as little load on the core team as possible.

Daniel
On Jun 13, 2011, at 12:30 PM, "Chris Marshall" <oxbowlakes@gmail.com> wrote:

It seems self-evident that bad documentation is worse than no documentation (or at least equivalently bad). Hence someone would have to painstakingly check your documentation and in particular any examples contained therein for correctness. As it's a reasonable assumption that the lack of documentation in the first place (which, in any case, is these days is not as much of a problem as it once was) is down to the available time of the scala committers, it follows that there's a good chance they won't have time to check any documentation which is "externally" provided.
Chris

On Mon, Jun 13, 2011 at 6:22 PM, Yuvi Masory < (ymasory [at] gmail [dot] com> wrote:

> It may not be the sexiest part of work but that's exactly what Scala
> eco-system is badly missing right now - the true commercial quality of
> software engineering that starts right from basic documentation.

I think writing documentation is sexy, but why would I even bother if
it will never get merged in?

Yuvi

Colladoc has incredible potential. I was totally bummed when Scalathon just did not have the budget to bring out Petr Hosek to promote the project and find no contributors.
Colladoc should continue getting attention, but we can't wait for it. In the meantime it should be a smooth and simple matter to fork scala/scala on GitHub, add your documentation and send a pull request. I did it a couple times and got stuff in. But it took a while, and if more people start doing it Paul will probably just go nuts :) Also it came after a long exchange of emails with him.
** Don't we have some trusted community members who can be trusted with commit access for documentation-only merges? **

Yuvi




On Mon, Jun 13, 2011 at 1:38 PM, Daniel Spiewak <djspiewak@gmail.com> wrote:
> This is where the beauty of something like colladoc becomes evident.  It's
> not just about crowd-sourcing the authoring, it's about crowd-sourcing the
> editing, checking, revision and final approval.
> We all appreciate the fact that the core committers are busy, and we
> appreciate the things that they're bust working on.  However, we can't just
> end the discussion there and accept a lack of documentation for the
> indefinite future.  We need to find a way to make this happen with as little
> load on the core team as possible.
>
> Daniel
> On Jun 13, 2011, at 12:30 PM, "Chris Marshall" <oxbowlakes@gmail.com> wrote:
>
> It seems self-evident that bad documentation is worse than no documentation
> (or at least equivalently bad). Hence someone would have to painstakingly
> check your documentation and in particular any examples contained therein
> for correctness. As it's a reasonable assumption that the lack of
> documentation in the first place (which, in any case, is these days is not
> as much of a problem as it once was) is down to the available time of the
> scala committers, it follows that there's a good chance they won't have time
> to check any documentation which is "externally" provided.
> Chris
>
> On Mon, Jun 13, 2011 at 6:22 PM, Yuvi Masory <ymasory@gmail.com> wrote:
>>
>> > It may not be the sexiest part of work but that's exactly what Scala
>> > eco-system is badly missing right now - the true commercial quality of
>> > software engineering that starts right from basic documentation.
>>
>> I think writing documentation is sexy, but why would I even bother if
>> it will never get merged in?
>>
>> Yuvi
>
>

On Mon, Jun 13, 2011 at 10:26 AM, Grand, Mark D <mgrand@emory.edu> wrote:

I would like to second that sentiment.  I like writing documentation after I have unearthed some undocumented details.  The last time I tried it, the documentation never made it into the code base.  I got the impression that documentation is not valued.

I think Colladoc is pretty close to ideal for this problem, and it's not too far off from where it needs to be.  Here's what I think it needs:
- Some assurance that colladoc submissions will never be discarded by accident, e.g. during an upgrade or migration -- the database should be backed up frequently and mirrored publicly - Something like a "Recent changes" view for people with a spare half hour to review recent progress- A few "social" features like voting for the best edit, commenting on edits, building a permalink to an edit, etc.
Of course, it's hard to see how much more could be shoehorned into the already very dense Scaladoc interface, so there really needs to be a "backend" view that's much more like a web *application* and doesn't try to be WYSIWYG.
-0xe1a

Chris Marshall escribió:

> It seems self-evident that bad documentation is worse than no documentation (or at least equivalently bad). Hence someone would have to painstakingly check your documentation and in particular any examples contained therein for correctness. As it's a reasonable assumption that the lack of documentation in the first place (which, in any case, is these days is not as much of a problem as it once was) is down to the available time of the scala committers, it follows that there's a good chance they won't have time to check any documentation which is "externally" provided.

Chris,

This point of view assumes that all parts of the codebase are equally important and complex. Sure, compiler internals probably cannot be documented by many community members but there are many sharp folks who have been using Scala for a while and they can document, say, Collections library very well, and can figure out a lot of details by simply reading the source.

Those people can improve many parts of documentation a great deal, if they know their changes have good chance of being merged in after a peer review. And keep in mind that Joe The Scala programmer doesn't typically look for compiler plugins documentation, but Collections library is something very relevant to him.

Agree on negativity - I 100% want to make sure that my comments are
viewed as constructive.

Now, I'm failing to see why we need anyone else to write Scaladoc
except for the person... who wrote the original code (or whoever
maintains it). What happened to that old principle that Javadoc/
Scaldoc is a code too and it is irrevocable part of the professional
software development? Scala code base (public one) is rather small at
this point and the effort should be rather minimal.

Crowd sourcing documentation may be fine in theory - but in practice
it may become a headache for someone who's going to colate it into
proper style/english/format.

In my company people own code *and* documentation equally. Grammar
mistake on incorrection in documentation is the same mistake as bug in
the code. There is simply no difference. This culture leads to better
overall quality.

On the other topic - I think there may be a general misconception on
what Typesafe goal is. Most of us assumed that it will stewardship
Scala as a language/eco-system and make it more digestible for
enterprise adoption as a technology in part due to its respectful
founders and financial stability. If Scala will still largely be
driven by effort of grads and volunteers (as it has been for the last
6-7 years) - so be it, but then we have to have clear expectation on
its quality and maturity.

It's not bad or good - but I think the community may have rather
unreasonably lofty expectation in this case.

Best,
--
Nikita Ivanov.
GridGain Systems.

On Jun 13, 8:35 am, Yuvi Masory wrote:
> Hi Martin,
>
> I'm glad things are moving forward. However, I'm pretty skeptical
> things will move forward unless there is someone with the time and the
> interest to *manage* contributions. Paul is the closest we have to a
> manager at the moment, but he's busy and by his own admission more
> interested in writing code of his own.
> We need a community liaison. Someone to answer questions, merge
> trivial pull requests (e.g., documentation), review other patches,
> coordinate volunteers, invite participation, etc, etc.
> We could have an army of volunteers (actually, I think we already do),
> but with the current structure of knowledge and permissions it's
> impossible for a volunteer to do anything other than get discouraged.
>
> Yuvi
>
>
>
>
>
>
>
> On Sun, Jun 12, 2011 at 7:17 PM, martin odersky wrote:
> > Hi Yuvi, all.
>
> > Thanks for this survey, it is really very useful for prioritizing things.
> > Now we need volunteers to actually do the things that were demanded. We have
> > some new people coming in at EPFL and there will be some reshuffling, so we
> > might be able to find volunteers internally for some of the things that were
> > mentioned. We'll discuss the survey at one of the next Scala meetings. It's
> > not going to be easy, precisely because Scala popularity is increasing
> > rapidly and there are a lot of interactions with people in the community to
> > be had. This is fundamentally a good thing. But it can also take a big toll
> > from a graduate student, who's first task is to publish papers and get his
> > or her thesis finished.  We'll also try to do what we can on the Typesafe
> > side, but again, resources are limited.
>
> > In summary we'll have to figure out how to do all this (because all the
> > points raised in the survey are worth doing). Any help from the community
> > would be greatly appreciated, and will in fact be essential.
>
> > We'll discuss and figure out a way to involve the community.
>
> > Best,
>
> >  -- Martin
>
> > ----------------------------------------------
> > Martin Odersky
> > Prof., EPFL and CEO, Typesafe
> > PSED, 1015 Lausanne, Switzerland
> > Tel. EPFL: +41 21 693 6863
> > Tel. Typesafe: +41 21 691 4967

Now, I'm failing to see why we need anyone else to write Scaladoc
except for the person... who wrote the original code (or whoever
maintains it).

Sometimes the person who wrote the code is not in a good position to
write the doc, because what can seem straight forward or self documenting
to him, will not be for others.

Crowd sourcing documentation may be fine in theory - but in practice
it may become a headache for someone who's going to colate it into
proper style/english/format.

There is already a very fine crowd sourcing tool, it's called GitHub.
I don't have an educated opinion on Colladoc, but the concept of
a wysiwyg front end to source control seems like a difficult challenge,
and I can't imagine how it can't be simpler than the GitHub pull request + merge tool,
or just plain GIT.

In my company people own code *and* documentation equally. Grammar
mistake on incorrection in documentation is the same mistake as bug in
the code. There is simply no difference. This culture leads to better
overall quality.

On the other topic - I think there may be a general misconception on
what Typesafe goal is. Most of us assumed that it will stewardship
Scala as a language/eco-system and make it more digestible for
enterprise adoption as a technology in part due to its respectful
founders and financial stability. If Scala will still largely be
driven by effort of grads and volunteers (as it has been for the last
6-7 years) - so be it, but then we have to have clear expectation on
its quality and maturity.

It's not bad or good - but I think the community may have rather
unreasonably lofty expectation in this case.

Best,
--
Nikita Ivanov.
GridGain Systems.

On Jun 13, 8:35 am, Yuvi Masory <ymas...@gmail.com> wrote:
> Hi Martin,
>
> I'm glad things are moving forward. However, I'm pretty skeptical
> things will move forward unless there is someone with the time and the
> interest to *manage* contributions. Paul is the closest we have to a
> manager at the moment, but he's busy and by his own admission more
> interested in writing code of his own.
> We need a community liaison. Someone to answer questions, merge
> trivial pull requests (e.g., documentation), review other patches,
> coordinate volunteers, invite participation, etc, etc.
> We could have an army of volunteers (actually, I think we already do),
> but with the current structure of knowledge and permissions it's
> impossible for a volunteer to do anything other than get discouraged.
>
> Yuvi
>
>
>
>
>
>
>
> On Sun, Jun 12, 2011 at 7:17 PM, martin odersky <martin.oder...@epfl.ch> wrote:
> > Hi Yuvi, all.
>
> > Thanks for this survey, it is really very useful for prioritizing things.
> > Now we need volunteers to actually do the things that were demanded. We have
> > some new people coming in at EPFL and there will be some reshuffling, so we
> > might be able to find volunteers internally for some of the things that were
> > mentioned. We'll discuss the survey at one of the next Scala meetings. It's
> > not going to be easy, precisely because Scala popularity is increasing
> > rapidly and there are a lot of interactions with people in the community to
> > be had. This is fundamentally a good thing. But it can also take a big toll
> > from a graduate student, who's first task is to publish papers and get his
> > or her thesis finished.  We'll also try to do what we can on the Typesafe
> > side, but again, resources are limited.
>
> > In summary we'll have to figure out how to do all this (because all the
> > points raised in the survey are worth doing). Any help from the community
> > would be greatly appreciated, and will in fact be essential.
>
> > We'll discuss and figure out a way to involve the community.
>
> > Best,
>
> >  -- Martin
>
> > ----------------------------------------------
> > Martin Odersky
> > Prof., EPFL and CEO, Typesafe
> > PSED, 1015 Lausanne, Switzerland
> > Tel. EPFL: +41 21 693 6863
> > Tel. Typesafe: +41 21 691 4967

On Mon, Jun 13, 2011 at 19:44, Yuvi Masory <ymasory@gmail.com> wrote:

Colladoc has incredible potential. I was totally bummed when Scalathon just did not have the budget to bring out Petr Hosek to promote the project and find no contributors.
Colladoc should continue getting attention, but we can't wait for it. In the meantime it should be a smooth and simple matter to fork scala/scala on GitHub, add your documentation and send a pull request. I did it a couple times and got stuff in. But it took a while, and if more people start doing it Paul will probably just go nuts :) Also it came after a long exchange of emails with him.

The problem here is that everyone except Paul still has to commit to SVN, thereforeintegrating a pull request form github requires manual work. This will be fixed once themain repository moves.  

** Don't we have some trusted community members who can be trusted with commit access for documentation-only merges? **

Yuvi




On Mon, Jun 13, 2011 at 1:38 PM, Daniel Spiewak <djspiewak@gmail.com> wrote:
> This is where the beauty of something like colladoc becomes evident.  It's
> not just about crowd-sourcing the authoring, it's about crowd-sourcing the
> editing, checking, revision and final approval.
> We all appreciate the fact that the core committers are busy, and we
> appreciate the things that they're bust working on.  However, we can't just
> end the discussion there and accept a lack of documentation for the
> indefinite future.  We need to find a way to make this happen with as little
> load on the core team as possible.
>
> Daniel
> On Jun 13, 2011, at 12:30 PM, "Chris Marshall" <oxbowlakes@gmail.com> wrote:
>
> It seems self-evident that bad documentation is worse than no documentation
> (or at least equivalently bad). Hence someone would have to painstakingly
> check your documentation and in particular any examples contained therein
> for correctness. As it's a reasonable assumption that the lack of
> documentation in the first place (which, in any case, is these days is not
> as much of a problem as it once was) is down to the available time of the
> scala committers, it follows that there's a good chance they won't have time
> to check any documentation which is "externally" provided.
> Chris
>
> On Mon, Jun 13, 2011 at 6:22 PM, Yuvi Masory <ymasory@gmail.com> wrote:
>>
>> > It may not be the sexiest part of work but that's exactly what Scala
>> > eco-system is badly missing right now - the true commercial quality of
>> > software engineering that starts right from basic documentation.
>>
>> I think writing documentation is sexy, but why would I even bother if
>> it will never get merged in?
>>
>> Yuvi
>
>

Colladoc has incredible potential. I was totally bummed when Scalathon just did not have the budget to bring out Petr Hosek to promote the project and find no contributors.
Colladoc should continue getting attention, but we can't wait for it. In the meantime it should be a smooth and simple matter to fork scala/scala on GitHub, add your documentation and send a pull request. I did it a couple times and got stuff in. But it took a while, and if more people start doing it Paul will probably just go nuts :) Also it came after a long exchange of emails with him.

The problem here is that everyone except Paul still has to commit to SVN, thereforeintegrating a pull request form github requires manual work. This will be fixed once themain repository moves.

It's also very important to note that using Git to collaborate (via pull requests) on commits that then get pushed via git-svn is very difficult and has a tendency to get very, very muddled.  (due to the way that git-svn rewrites commits)  I've experienced this on three different projects now, so this isn't just a hypothetical concern.   Until the canonical repo moves, GitHub isn't going to be the panacea of collaboration that we would like it to be.

Daniel

I just wanted to let you know your feedback is appreciated, and we have been discussing each suggestion internally.
We will respond on google moderator in a few days, as soon as we've had the time to write up our answers.
cheersadriaan

Fantastic!
Please everyone go back to Google moderator and vote on the new suggestions that were posted after you last visited the site. Ray Racine added a cool one just yesterday.http://www.google.com/moderator/#16/e=945de

Yuvi



On Wed, Jun 29, 2011 at 4:13 AM, Adriaan Moors <adriaan.moors@epfl.ch> wrote:

I just wanted to let you know your feedback is appreciated, and we have been discussing each suggestion internally.
We will respond on google moderator in a few days, as soon as we've had the time to write up our answers.
cheersadriaan

How's that response coming Adriaan?

Yuvi



On Wed, Jun 29, 2011 at 4:13 AM, Adriaan Moors <adriaan.moors@epfl.ch> wrote:

I just wanted to let you know your feedback is appreciated, and we have been discussing each suggestion internally.
We will respond on google moderator in a few days, as soon as we've had the time to write up our answers.
cheersadriaan

Hi Yuvi, all,

Thanks again for everyone who made suggestions on:

http://www.google.com/moderator/#15/e=945de&t=945de.40&f=945de.419b8c

We think most of these suggestions are very good and will do our best to implement as many of them as we can. Of course, resources are finite, so we do have to prioritize.

Here are the detailed responses, as discussed on EPFL's Scala meeting on June 28 (and yes, one of the responses is that we will again make meeting notes public in the future).

Cheers

 -- Martin and Adriaan

• concerted effort of moving to git&sbt
• We are working on a multi-stage, concerted effort of moving to GitHub for hosting  our code and SBT to build the distribution. The main push will start mid-August. We have already gradually been refining our tooling infrastructure, but this remains a major effort. As far as GitHub is concerned, the repository is already there, even though SVN has remained the central, official repository. Beyond “simply” bootstrapping the compiler using SBT (which in itself is no mean feat), many more Ant tasks remain to be ported. Contributions are more than welcome here!
• have shadow of repo in git that’s being used more and more before that
• core build: Mark (need proof of concept asap to verify that the whole bootstrap works)
• lots of other existing ant scripts (docs, publishing, website, manuals, tests,....)
• GitHub move: see above
• SBT move: see above
• Treat core lib docs more seriously: Heather is doc-czarina
• Heather Miller has stepped up to be the Documentation Czar. She will oversee the quality of existing documentation, identify where it is missing, and improve it by accepting contributions and actively looking for people who are in a position to document specific areas. Additionally, we are fleshing out a reviewing policy that specifies minimal requirements for documentation, among other things.
• Sending meeting notes: agree
• We will soon start sending summaries of our meeting notes to scala-internals again.
• Transparent process for minor patches: must be low-effort for core committers as well. Use pull requests when we move to git.
• Once the move to GitHub is complete, our community liaison will be in charge of accepting “trivial” pull requests, and redistributing more involved ones to the person responsible for the concerned aspect.
• Incubator/greenhouse:
• We agree that this would be very worthwhile. We are still working out the details on how to staff this. It’s a pretty large effort that requires some people who are intimately familiar with many aspects of the Scala ecosystem and furthermore someone with good taste and high standards. Originally, we had Paul Phillips penciled in in that role, but he is far too busy to be able to spend the time necessary for this. Suggestions for people who could do this are very welcome.

• Point of contact for website improvements:
• Please use the contact form to submit suggestions for improvement.
• Some of the aspects could be taken over by a community liaison person.
• Community involvement in decisions about improving stdlib vs. backward compatibilty:
• Please rest assured that we are as interested in involving you in our decision process as you are in guiding it. We are very glad to have such an active and insightful community.
• The private committers-only list should be used sparingly and more of the planning should be done in the open:
• What happens on the internal mailing lists and during meetings rarely stays there -- unless it is clearly of no outside interest. We value community feedback tremendously. scala-devel is actually only used very sparingly, and we believe it fulfils a small but critical role (e.g. one can openly criticize a person without it becoming public knowledge).
• Appoint a community liaison person
• Agreed.
• The commit ml should only deal with issues directly related to committing - software and hardware for commits, and perhaps some aspects of the governance of granting and rescinding commit rights. Everything else should be on a public scala-<foo>.
• See above.
• Package Object Based Module System Allow for the definition of the public interface(s) to an entire package:
• This is an interesting improvement, but we currently do not have the resources to implement it. If someone wants to step up doing it they are more than welcome. The last two times we went through this discussion, people were pushing very hard but then nothing whatsoever happened. So we are naturally sceptical that this would be different now, but are willing to be shown otherwise.
• Investigate how Scala can be used on Android without using ProGuard. Could the Scala standard libraries be broken into pieces so scala code code could run without ProGuard? (ProGuard slows down the dev process substantially.)
• This is an interesting improvement, but we currently do not have the resources to implement it. (see answer to module system).
• Moderate scala-users:
• First posts are already being moderated.

On Thu, Jul 7, 2011 at 8:21 AM, martin odersky <martin.odersky@epfl.ch> wrote:

• Package Object Based Module System Allow for the definition of the public interface(s) to an entire package:
• This is an interesting improvement, but we currently do not have the resources to implement it. If someone wants to step up doing it they are more than welcome. The last two times we went through this discussion, people were pushing very hard but then nothing whatsoever happened. So we are naturally sceptical that this would be different now, but are willing to be shown otherwise.

I stuck that on the list because I have had a moment or two where it would be "nice" to have something along the lines of package level encapsulation, but certainly not a "must" have situation.   Absolutely any effort spent in this area now would be premature given the deferring of addressing modules (Project Jigsaw) in Java 8 [1].   Not only would much of the heavy lifting in this area be done gratis, but the true utility would manifest as well.  
[1] http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#module-dependences
Ray

Hi Martin,
Thank you so much for the detailed comments. I don't have much to say about most of these suggestions (as they weren't mine to begin with), but I do have a couple comments.

• Treat core lib docs more seriously: Heather is doc-czarina
• Heather Miller has stepped up to be the Documentation Czar. She will oversee the quality of existing documentation, identify where it is missing, and improve it by accepting contributions and actively looking for people who are in a position to document specific areas. Additionally, we are fleshing out a reviewing policy that specifies minimal requirements for documentation, among other things.

I am delighted to hear this. I'd love to see a webpage describing the official procedures and policies as soon as she can write them.  

• Appoint a community liaison person
• Agreed.

I can't wait. This person will need a Gmail storage upgrade to handle all the emails they'll get.
Cultural Issues: Organizing events in recent years, especially Scalathon, has taught me that merely saying "volunteers needed" never leads to anyone volunteering. I'd love to see a culture of Martin, Paul, and others sending people emails that say HEY YOU! DO XYZ! Sounds gruff, but people often feel honored to be asked, and when it's more spelled out of them, and they know the core committers are paying attention to them, it works out. So yeah, asking very very directly for help I think can propel things forward.
Good luck with the list.
Yuvi

Thanks a lot for the update Martin and Adriaan. I believe the build and repository improvements will result in more contributions (and hopefully) more regular contributors to Scala.
Best,Ismael

On Thu, Jul 7, 2011 at 2:21 PM, martin odersky wrote:
> Investigate how Scala can be used on Android without using ProGuard. Could
> the Scala standard libraries be broken into pieces so scala code code could
> run without ProGuard? (ProGuard slows down the dev process substantially.)
>
> This is an interesting improvement, but we currently do not have the
> resources to implement it. (see answer to module system).

Please visit https://github.com/jrudolph/scala-android-libs