gistfile1.txt

I'd like some clarification about Ruby 2.0:

* Is it intended to be a development release?
* If it is not a development release, why are experimental features included?
* Whether or not it is a development release, what process will be used to remove
  features after release? (For example, we still have $' and friends years after
  Matz has repeatedly said he wouldn't add them in retrospect.)
* Why are APIs like IO.readlines not being fixed to use keyword arguments?
* Why are API changes not being added to RubySpec?
* Is Ruby 2.0 expected to pass RubySpec before release? (This does not allow for
  just excluding failing specs.)

Regarding a Ruby design process:

* What is "Ruby"?
* Will implementations of Ruby other than MRI be treated as equal implementations
  and not "alternative" implementations?
* If we do not agree on RubySpec as the project to create a complete executable
  specification of Ruby, then what alternative should be used that fully supports
  versions, implementations, platforms, and optional/undefined behavior without
  mixing implementation details like MRI bugs?
* I am willing to supply a web application that formalizes design changes with
  commentary by implementers that can be linked to enumerated paragraphs of a
  proposed change, source code for each implementation, RubySpec coverage, and
  votes. If I created this, would it be used? If not, why not?
* Will Matz accept the idea of a "Ruby design council" in any form that has authority
  to override Matz's decision or is Matz explicitly stating that he is the (B)DFL?

I'd like some clarification about Ruby 2.0:

• Is it intended to be a development release?

This seems to be a question about MRI, not Ruby 2.0. I think (in this meeting) we should focus on separating "MRI the implementation" from "Ruby the language".

• If it is not a development release, why are experimental features included?

A language design process would not prohibit experimental features in various implementations. We should propose that experimental features be "opt-in". For example, Rubinius's Actor model is not Official Ruby™, but does ship with Rubinius.

• Whether or not it is a development release, what process will be used to remove
  features after release? (For example, we still have $' and friends years after
  Matz has repeatedly said he wouldn't add them in retrospect.)

If you are interested in championing a proposal to remove these features, that would be awesome! I think it would be worthwhile for you to submit a straw man proposal.

• Why are APIs like IO.readlines not being fixed to use keyword arguments?

This would be a great proposal for you to champion (if you feel strongly about it).

• Why are API changes not being added to RubySpec?

It seems that some are. Naruse (a member of the ruby-core team) has been adding them. RubySpec should be the endpoint of the design process. Not every proposal champion will be able to write specs that completely live up to RubySpec standards, so hopefully we can look to you to help get the specs up to snuff.

• Is Ruby 2.0 expected to pass RubySpec before release? (This does not allow for
  just excluding failing specs.)

MRI may not be fully Ruby 2.0 compliant. We would expect that the initial release of MRI 2.0 would have bugs and gaps between the specified behavior and the implementation. Early implementations will help us flesh out the specification based on implementor feedback.

Regarding a Ruby design process:

• What is "Ruby"?

This is what our team must decide via the language design process.

• Will implementations of Ruby other than MRI be treated as equal implementations
  and not "alternative" implementations?

The language design team should consist of core members beyond just MRI, and arrive at decisions through consensus.

• If we do not agree on RubySpec as the project to create a complete executable
  specification of Ruby, then what alternative should be used that fully supports
  versions, implementations, platforms, and optional/undefined behavior without
  mixing implementation details like MRI bugs?

RubySpec should be the end point of the language design process.

• I am willing to supply a web application that formalizes design changes with
  commentary by implementers that can be linked to enumerated paragraphs of a
  proposed change, source code for each implementation, RubySpec coverage, and
  votes. If I created this, would it be used? If not, why not?

It's difficult to commit to using something you've never seen. For now, this is an experimental process. We should try to use existing tools until we figure out how the process will flow best. Then we should refactor it to a tool customized for our process.

• Will Matz accept the idea of a "Ruby design council" in any form that has authority
  to override Matz's decision or is Matz explicitly stating that he is the (B)DFL?

I think so, but it depends on the arguments used. I think he is willing to experiment, but we'll need to show him that this experiment is productive. I hope that this question will be addressed in my first agenda item.

I believe that the goals of your agenda items are the same goals that led to the language design team. I am excited to for you to be a part of this!