Minutes of the 8th meeting of the Scala Center, Q1 2018

Minutes are archived on the Scala Center website.


The following agenda was distributed to attendees: agenda.

Scala Center activities for the past quarter focused on MOOCs, scalajs-bundler, collections, Build Server Protocol (BSP), Scala Native tooling API, Scala Platform Process (SPP), Scala Improvement Process (SIP), Scala compiler performance and profiling, Zinc, Scalameta, Scalafix, and Scala Days program organization.

Full details on these activities are in Heather’s report.

Other topics discussed at the meeting included macros, governance, Scala 3, and the planned Scala contributors summit in Berlin.

Two new proposals were made:

  • SCP-016: Accessible Scala (community)
    • voted on and accepted
  • SCP-017: Support for LSP and STP Working Groups (Twitter)
    • voted on and accepted

Date, Time and Location

The meeting took place virtually, via Google Meet, at 4:00pm (UTC) on Friday, March 16, 2018.

Minutes were taken by Seth Tisue (secretary).


Attendees present

Board members:

  • James Belsey, Morgan Stanley
  • Francisco Díaz, 47 Degrees (filling in for Raúl Raja Martínez)
  • Thomas Gawlitza, SAP
  • Stu Hood, Twitter
  • Lars Hupel, community/Typelevel
  • Adriaan Moors, Lightbend
  • Frederick Reiss, IBM
  • Haripriya Srinivasaraghavan, Verizon
  • Arnaud Payement, Goldman Sachs (filling in for Jonathan Perry)
  • Bill Venners, community/Artima


  • Rui Batista, e.near
  • Eugene Burmako, Twitter


  • Heather Miller (director), EPFL
  • Jon Pretty (chairperson), Propensive
  • Martin Odersky (technical advisor), EPFL
  • Seth Tisue (secretary), Lightbend


As chairperson, Jon Pretty conducted the meeting.


As Executive Director, Heather Miller summarized Scala Center activities since the last meeting.

Most of Heather’s remarks were based on her detailed report on the Center’s recent activities.

The following notes are a supplement to Heather’s report.

Seth asked whether there’s any prospect of the Dotty “Principled Meta Programming” effort, which has replaced the Scala Center’s previous portable-macros effort, ever being backported to Scala 2. Martin said it’s Scala 3 only. The recommended migration strategy is for macro authors to port their macros to the new system for Scala 3. Jon suggested that a blog post be published explaining this further. Seth praised the clarity of the new situation; the community had been worried about having to rewrite their macros twice, once before Scala 3, and once after.

Lars asked if we’re voting on the portable-macros effort being dropped; the answer’s no. James asked about the process involved, for the board, in abandoning an approved proposal. That’s not clear, but since no one is actually objecting, we didn’t pursue that question further. Adriaan suggested that requesting a vote, and/or submitting a followup proposal, both seem like plausible routes, should such a situation arise in the future.

Financial report

Verizon is leaving the board after this quarter. Other than that, the Center’s financial situation remains unchanged since last quarter.


SCP-016: Accessible Scala

Proposed by Bill Venners and Lars Hupel on behalf of the FLOSS community.

The proposal was written by Sam Halliday, with input from Jon Pretty and Rui Batista.

See the proposal text for details.

Jon summarized the proposal for the board, and Rui Batista, a guest at the meeting, explained how work on this would benefit him and other Scala developers who are blind or partially-sighted.

Rui emphasized that there is an opportunity here to leverage Scala’s rich type system, as well of Scalameta’s understanding of types, to aid blind developers much more than existing systems for other programming languages can do.

Jon mentioned that there is some existing work on GitHub, by a user named Maxwell, that could give the effort a head start.

Heather addressed the issue of staffing. She thinks the required effort level is modest enough that the Center could reasonably fit it in, and that Guillaume Massé would be a suitable engineer.

Lars asked Rui if he could estimate how much this tool might actually speed his coding work up. Rui declined to name a number, but offered that the most dramatic speedup would come from an “outline” or “overview” mode, that used its knowledge of code structure to avoid having to read the entire file out loud.

Voting: all in favor, none opposed, no abstentions. The proposal is accepted.

SCP-017: Support for LSP and STP Working Groups (Twitter)

Proposed by Stu Hood and Eugene Burmako (Twitter).

See the proposal text for details.

Eugene presented the proposal to the board. Jon and Heather discussed the nature of the support that the Scala Center could provide to the working groups; the proposal deliberately leaves that rather open. Heather said that Jorge and Ólafur (but Jorge especially) would be the engineers most involved.

Bill and James were unclear on the costs involved. Jon clarified that the “Costs” section refers to other costs besides developer effort.

But apart from that, Bill thought the effort level proposed seemed surprisingly high. Heather and Eugene clarified that the effort level would involve some engineering work as well as just participating in discussions. Eugene described 5 developer days/week as only “a start” at what it might take to tackle a problem this big.

James suggested that the board not commit to supporting a whole year of that effort level, but reevaluate by re-voting in six months. Stu thought that sounded fine, and there were no objections from the rest of the board, so that’s the version of the proposal Jon put a vote.

Seth asked, at this point, whether Bloop work is covered by this proposal.

Heather acknowledged that she isn’t sure yet about Bloop’s “niche”, but she thinks that any work that happens on Bloop can be “repurposed” if necessary, depending on what the STP working group decides.

Also, Stu had asked, earlier in the meeting, for clarification on the goals of Bloop. Will users be confused by having a third tool involved, in addition to their IDE and their build tool? The success of Bloop could depend on really good integration that smooths that over. Further discussion on this will occur in the working groups themselves, of course. Jon suspects that although Bloop currently has its own “branding”, it could end up “integrated” into something else.

Jon described the working groups as, in part, an “experiment” to see whether “this approach to decision making” works. Yes, some early work on Bloop happened without much guidance from the board or the groups, but if the groups are established, the work would continue in that context.

Bill and Heather returned to the question of effort level – does the Center have enough engineers to do this? As usual, accepted proposals are recommendations, not commands; Heather thinks effort levels on various projects can be adjusted as needed.

Voting: all in favor, none opposed, no abstentions. The proposal is accepted.

Other business

Bill didn’t have any community feedback to relay. Lars had to leave the meeting early.

Jon re-raised the governance question about the portable macros effort. Heather proposed that the advisory board meetings are the right venue to re-discuss and perhaps re-vote when something like this occurs. Stu observed that the Center doesn’t control the Dotty team; external circumstances can change. James thought “what we have is fine”, probably. Three months can be a long cycle, but the advisory board mailing list exists when communication needs to happen faster, for example in the monthly updates sent there. There seemed to be general agreement that monthly is fast enough.

Jon observes that there tends to be a flurry of activity immediately before meetings, which doesn’t leave much time for thought and discussion ahead of time. The communication of the decision on macros was an example of this. We should try to break out of that pattern if we can. Perhaps by setting a proposal deadline longer before the meeting? But then what about counterproposals? It’s unclear how to handle this.

Stu asked if there are forums the Scala Center uses for discussion that board members could join as well, in addition to following GitHub issues. Heather said that some board members are restricted to email for regulatory reasons, so it’s not obvious what technology to use. No conclusion on this was reached.

Martin shared plans for Scala 3: “it should come out shortly after Scala 2.14.” Eugene asked about migration, especially macros. Martin mentioned Scalafix, and said it needs to be “accelerated” for Scala 3 migration purposes. Macros are the “biggest worry”, so the team needs to take “controlled steps” in this area and not be “overly ambitious”. By the end of 2018 the story there should be clearer. The Lightbend team will focus on the 2.14 release, which will be “the best version they can make to enable the migration”. The two teams will “work from both sides” to make it happen and provide migration paths.

Heather announced that she is organizing a contributors summit after Scala Days Berlin in June, to bring together people working on Scala compilers, tooling, and libraries for roundtable discussions. The format will be based on the Go contributors summit.


Planning of next meeting, can we have it at Scala Days NYC in June? Most board members will be present, so we can have the meeting in person, and anyone who can’t make it can still attend remotely. James Belsey suggested meeting at Morgan Stanley’s offices, so that’s the tentative plan.