Submitted by: Trans Onoma
This revision by: Trans Onoma
Date: Thu Aug 09 19:05:47 -0400 2007
A light bulb went off in my head this evening—why not bootstrap the issue and submit an RCR about the RCR process itself? And so I have.
RCRchive’s current design is ineffective, for both end-users and Ruby’s developers. I will propose a small set of minimal changes that I am sure will improve the situation immensely.
RCRchive is ineffective for a variety of reasons:
1) The website, while fairly good, lacks the ability to collaborate or evolve RCRs prior to submission. Many RCRs might not even be officially submitted if their proponents first received constructive overviews from the community. Or they could be made that much better before submission if peers could make pre-submission suggestions.
2) Having one mailing-list per RCR presents a number of issues:3) There is a lack of stated procedure on the receiving end of the process. What happens if an RCR gets wide support, for instance? Doesn’t that warrant a formal analysis, so to speak, by the the Ruby-core team? Having some form of procedures along these line, even if stiff, makes people feel involved and makes it worth their time and effort. There’s no point in counting votes if votes don’t mean anything.
4) Finally, as a minor point, while the website if quite functional, it could use a little cosmetic enhancements. For instance, the field below this one, called “Proposal”, is distorted and shoved off to the right.
The above issues can be addressed with some very simple changes:
1) Create a dedicated mailing list for RCR discussions, and adjust RCRchive to use this list instead of the multitude of lists it currently uses.
2) Allow an RCRs to have multiple authors. Only authors can change an RCR, and add or remove other authors.
3) Add a ‘development’ status, that comes before ‘pending’.
4) Offer some standard procedures for the consideration process.
5) Have a design specialist, like John Long, take an afternoon or two cleaning-up and beautifying the site.
As you surely know, I’ve been arguing many of these point for for some time. This is simply because it is important to me. Dreaming about Ruby what-ifs (and what-ifs in general) is a hobby of mine. And for this reason I believe I probably have effective insight into what would make a good venue for the activity.
Other solutions have been tried. We are already at the third incarnation of the RCR process (that I know of). It seems a prudent time to give this approach a try, especially with the eminent releases of Ruby 1.9 and 2.0.
There are four parts to implementation:
1) Setting up the mailing list.
2) Functional adjustments to RCRChive.
3) Matz and core-team developing some consideration procedures.
4) Beautification of the site.
I support parts of this proposal. These are all good ideas: 1) Create a dedicated mailing list for RCR discussions, and adjust RCRchive to use this list instead of the multitude of lists it currently uses. 3) Add a 'development' status, that comes before 'pending'. This is less important to me: 4) Offer some standard procedures for the consideration process. This is not important at all to me: 2) Allow an RCRs to have multiple authors. Only authors can change an RCR, and add or remove other authors. 5) Have a design specialist, like John Long, take an afternoon or two cleaning-up and beautifying the site. I think that there is no problem with someone working with a few others to develop an RCR but ultimately I think one person should be responsible for maintaining it and seeing it through the process, just to limit administrative complexity. Also, on this meta RCR, a meta-meta comment, if there *were* to be some standard procedures, I'd recommend one to be that people don't use the RCRchive to reference personal issues. I can only respond to the following with 'who cares?' "As you surely know, I've been arguing many of these point for for some time. On occasion I have even become heated about it. This is simply because it is important to me. Dreaming about Ruby what-ifs (and what-ifs in general) is a hobby of mine" I mention this only because I feel like in the Analysis section of an RCR, perhaps you should be discussing the technical merits of an RCR and its effects, not the personal issues that it may have arised from.
On 8/9/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote: > A comment about: RCR 14: Updated RCRchive > was sent by Gregory Brown. > > To send a comment, reply to this mail. Please trim all unnecessary > lines. > > You can view RCR 14 at: > https://rcrchive.net/rcrs/14 > > I support parts of this proposal. > > These are all good ideas: > > 1) Create a dedicated mailing list for RCR discussions, and adjust > RCRchive to use this list instead of the multitude of lists it > currently uses. > > 3) Add a 'development' status, that comes before 'pending'. > > This is less important to me: > > 4) Offer some standard procedures for the consideration process. > > This is not important at all to me: > > 2) Allow an RCRs to have multiple authors. Only authors can change an > RCR, and add or remove other authors. > > 5) Have a design specialist, like John Long, take an afternoon or two > cleaning-up and beautifying the site. > > I think that there is no problem with someone working with a few > others to develop an RCR but ultimately I think one person should be > responsible for maintaining it and seeing it through the process, just > to limit administrative complexity. The Cut-based RCR was a joint project by myself and Peter Vanbroekhoven. We spent months editing it, and we would take turns working on it. It proved a very powerful way to work. It simply wouldn't have been as easy or turned out as well, had we non been able to do this (we used ruby garden wiki to accomplish this, btw). So I can understand, that it may not be priority #1. But it has value and really it shouldn't be hard to implement. RCRchive is a Rails app after all. > Also, on this meta RCR, a meta-meta comment, if there *were* to be > some standard procedures, I'd recommend one to be that people don't > use the RCRchive to reference personal issues. I can only respond to > the following with 'who cares?' > > "As you surely know, I've been arguing many of these point for for > some time. On occasion I have even become heated about it. This is > simply because it is important to me. Dreaming about Ruby what-ifs > (and what-ifs in general) is a hobby of mine" > > I mention this only because I feel like in the Analysis section of an > RCR, perhaps you should be discussing the technical merits of an RCR > and its effects, not the personal issues that it may have arised from. Point taken. I was only trying to emphasis the merits of my approach based on my dedication to the subject matter. I've reduced the statement a bit in my last update. I also think this proves the point about the 'development' status. T.
On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote: > The Cut-based RCR was a joint project by myself and Peter > Vanbroekhoven. We spent months editing it, and we would take turns > working on it. It proved a very powerful way to work. It simply > wouldn't have been as easy or turned out as well, had we non been able > to do this (we used ruby garden wiki to accomplish this, btw). So I > can understand, that it may not be priority #1. But it has value and > really it shouldn't be hard to implement. RCRchive is a Rails app > after all. I think that perhaps it would be reasonable to give more than one person *access* to refining an RCR while it is in development stage, but that once it is submitted, one person should own it. This is so that there would be a single point of contact for the core team and one person responsible for ultimately making sure the RCR makes it through the process properly. But with that in mind, I'm not entirely sure we need more software to do that. A dedicated mailing list for RCR discussion combined with ad-hoc wiki pages would probably solve the problem just fine without taking up David's time (or whoever is maintaining the RCRchive). > > I mention this only because I feel like in the Analysis section of an > > RCR, perhaps you should be discussing the technical merits of an RCR > > and its effects, not the personal issues that it may have arised from. > > Point taken. I was only trying to emphasis the merits of my approach > based on my dedication to the subject matter. I've reduced the > statement a bit in my last update. Unfortunately, I saw it as taking away from an otherwise reasonable request. > I also think this proves the point about the 'development' status. Yes. definitely.
Hi --
On Sun, 12 Aug 2007, gregory.t.brown@gmail.com wrote:
> A comment about: RCR 14: Updated RCRchive
> was sent by Gregory Brown.
>
> To send a comment, reply to this mail. Please trim all unnecessary
> lines.
>
> You can view RCR 14 at:
> https://rcrchive.net/rcrs/14
>
> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
>
>> The Cut-based RCR was a joint project by myself and Peter
>> Vanbroekhoven. We spent months editing it, and we would take turns
>> working on it. It proved a very powerful way to work. It simply
>> wouldn't have been as easy or turned out as well, had we non been able
>> to do this (we used ruby garden wiki to accomplish this, btw). So I
>> can understand, that it may not be priority #1. But it has value and
>> really it shouldn't be hard to implement. RCRchive is a Rails app
>> after all.
>
> I think that perhaps it would be reasonable to give more than one
> person *access* to refining an RCR while it is in development stage,
> but that once it is submitted, one person should own it. This is so
> that there would be a single point of contact for the core team and
> one person responsible for ultimately making sure the RCR makes it
> through the process properly.
>
> But with that in mind, I'm not entirely sure we need more software to
> do that. A dedicated mailing list for RCR discussion combined with
> ad-hoc wiki pages would probably solve the problem just fine without
> taking up David's time (or whoever is maintaining the RCRchive).
The current arrangement is:
* One mailing list per RCR.
* Anyone on the mailing list for RCR x can edit RCR x.
* All previous revisions are available.
* Matz sees all of it.
Whatever RCRchive does, there's always going to be the possibility of
discussing and refining RCRs somewhere else, if you want to. It's
literally impossible for RCRchive to subsume all possible discussion
of changes to Ruby, and that never has been, and never will be, a
goal.
Also, just to reiterate an important point, RCRchive is strictly based
on implementing a blueprint delivered by Matz. I'm not going to
change it, unless I hear from Matz. So if I appear to be ignoring or
stonewalling this discussion, that's why: there's no action required
or even possible on my part based on general public discussion of what
people think RCRchive should do.
I would strongly recommend the "bend before you break" principle --
meaning, just use email and wikis as needed and participate in the RCR
process when you feel comfortable and ready to do so. ("You" meaning
"everyone", not Greg specifically.)
David
On 8/12/07, dblack@rubypal.com <dblack@rubypal.com> wrote:
> I would strongly recommend the "bend before you break" principle --
> meaning, just use email and wikis as needed and participate in the RCR
> process when you feel comfortable and ready to do so. ("You" meaning
> "everyone", not Greg specifically.)
With that in mind, let me suggest something to Tom:
Maybe all we need is an rcr-discuss google group?
Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
that solve the problem of overall discussion?
Or if you feel like that's making it a second-class citizen... David,
would you be willing to host an rcr-discuss mailing list at RCRchive?
I'm not suggesting making any changes beyond that, but it' be a good
place for this 'all in one' pre-discussion stuff.
I'm generally not one to care much about formal process, I just want
the RCR process to seem friendly and like it is effective. Maybe a
small change like that would do so. It'd also give a place for Matz
to participate in the pre-discussions if he wants without sifting
through RubyTalk.
On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote: > > > With that in mind, let me suggest something to Tom: > > Maybe all we need is an rcr-discuss google group? > > Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would > that solve the problem of overall discussion? > > Or if you feel like that's making it a second-class citizen... David, > would you be willing to host an rcr-discuss mailing list at RCRchive? > I'm not suggesting making any changes beyond that, but it' be a good > place for this 'all in one' pre-discussion stuff. > > I'm generally not one to care much about formal process, I just want > the RCR process to seem friendly and like it is effective. Maybe a > small change like that would do so. It'd also give a place for Matz > to participate in the pre-discussions if he wants without sifting > through RubyTalk. > Sounds pretty cool an idea, while I cannot talk for Tom I feel that this approach will allow us to identify the *real* needs of RCR. I appreciate the thinking work Tom has done, but to jump there would be an err optimistic approach. Gregory's idea seems a good idea for a first step. Maybe that first step will be enough, maybe it will lead us into a new direction, maybe a second step into the same direction will just follow, who knows? Let us try to find out :). Cheers Robert
Hi --
On Sun, 12 Aug 2007, gregory.t.brown@gmail.com wrote:
> A comment about: RCR 14: Updated RCRchive
> was sent by Gregory Brown.
>
> To send a comment, reply to this mail. Please trim all unnecessary
> lines.
>
> You can view RCR 14 at:
> https://rcrchive.net/rcrs/14
>
> On 8/12/07, dblack@rubypal.com <dblack@rubypal.com> wrote:
>
>> I would strongly recommend the "bend before you break" principle --
>> meaning, just use email and wikis as needed and participate in the RCR
>> process when you feel comfortable and ready to do so. ("You" meaning
>> "everyone", not Greg specifically.)
>
> With that in mind, let me suggest something to Tom:
>
> Maybe all we need is an rcr-discuss google group?
>
> Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
> that solve the problem of overall discussion?
>
> Or if you feel like that's making it a second-class citizen... David,
> would you be willing to host an rcr-discuss mailing list at RCRchive?
> I'm not suggesting making any changes beyond that, but it' be a good
> place for this 'all in one' pre-discussion stuff.
I think you'll be better off with a Google group than anything hosted
at RCRchive. Keep in mind, though, that there's no "all in one"
possible; you can't stop other people from discussing Ruby changes
anywhere else. The fact that Matz has commissioned a centralized
site, and people are talking about creating alternatives, is proof of
that :-)
Besides, "pre" is in the mind of the beholder. I worry about every
RCR evolving into a discussion about whether or not it was
pre-discussed enough, etc.... rather than just discussed on its own
merits.
> I'm generally not one to care much about formal process, I just want
> the RCR process to seem friendly and like it is effective. Maybe a
> small change like that would do so. It'd also give a place for Matz
> to participate in the pre-discussions if he wants without sifting
> through RubyTalk.
I've never heard him say that he wants a separate list or group for
change discussions, and I've been dealing with him in detail about
this for years. What he's said he wants is what I've tried to
implement in RCRchive. That doesn't mean he'll never change the
process, but as things stand, the process is in place.
It would be good if someone could create whatever new forum is
brewing, and then move this discussion there. I'd rather try to keep
RCRchive itself focused on language change requests, and not itself.
David
On 8/12/07, dblack@rubypal.com <dblack@rubypal.com> wrote: > I've never heard him say that he wants a separate list or group for > change discussions, and I've been dealing with him in detail about > this for years. What he's said he wants is what I've tried to > implement in RCRchive. That doesn't mean he'll never change the > process, but as things stand, the process is in place. This is a good point. The format we have here is what Matz wants, which I think is more important than what the community wants (at least for this purpose). Of course, if there was a huge backlash of folks wanting this to be changed, I think it'd be a different story. That doesn't seem to be the case though. > It would be good if someone could create whatever new forum is > brewing, and then move this discussion there. I'd rather try to keep > RCRchive itself focused on language change requests, and not itself. Sounds reasonable to me. I was mainly suggesting an alternative, not necessarily advocating that it should exist. (I've voted neutral on this request because it's exactly how I feel :) If someone wants to fire up a google group, just link it here and I'll follow you there, I suppose.
On 8/12/07, robert.dober@gmail.com <robert.dober@gmail.com> wrote: > Sounds pretty cool an idea, while I cannot talk for Tom I feel that > this approach will allow us to identify the *real* needs of RCR. > I appreciate the thinking work Tom has done, but to jump there would > be an err optimistic approach. > Gregory's idea seems a good idea for a first step. > Maybe that first step will be enough, maybe it will lead us into a new > direction, maybe a second step into the same direction will just > follow, who knows? > > Let us try to find out :). I'm afraid it's not enough. I tried that a few years back with a 'ruby-muse' mailing list. It got a little traction but not enough to sustain itself. Sadly people would even down me and that list when I tried to drum up support for it. It simply wasn't officially endorsed by Matz or the core team, so few people cared. When were talking about an RCR process you have to have official support or it just won't fly. Unfortunately Matz seems pretty apathetic about the whole thing. I don't know why. I know there are certain people on the core team that are very arrogant, and don't give a hoot what anyone else thinks that isn't a grandmaster C coder. So maybe they are steering Matz away from a working RCR process. I don't know. But honestly, he might as well shut the whole thing down. Compared to Perl, Python, Erlang and even Rebol, Ruby's RCR process seems almost like a bad joke, which is really too bad b/c it has the potential to be better than any of those. http://dev.perl.org/perl6/rfc/ http://www.python.org/dev/peps/ http://www.erlang.org/eep.html * http://www.rebol.net/cgi-bin/r3blog.r T. * Erlang's looks exceptionally good. But I still think Ruby's could be even better.
On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote: >Compared to Perl, Python, Erlang and even > Rebol, Ruby's RCR process seems almost like a bad joke, which is > really too bad b/c it has the potential to be better than any of > those. Please consider discussing this privately. I think it's far outside the scope of what the RCRchive is for.
On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote: > A comment about: RCR 14: Updated RCRchive > was sent by Gregory Brown. > > To send a comment, reply to this mail. Please trim all unnecessary > lines. > > You can view RCR 14 at: > https://rcrchive.net/rcrs/14 > > On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote: > > >Compared to Perl, Python, Erlang and even > > Rebol, Ruby's RCR process seems almost like a bad joke, which is > > really too bad b/c it has the potential to be better than any of > > those. > > Please consider discussing this privately. I think it's far outside > the scope of what the RCRchive is for. You know, I'm just not doing it anymore. You all can talk wherever you all want. Every where I've turned with this I'm told to go else where. If Ruby's own RCR process can't talk about Ruby's RCR process, then for heaven's sake, do we need a MetaRCRrchive? You can tip toe on ice all you want, but if the ice is weak it's going to break. That's where this process is, ''-this close to oblivion, and you all are nitpicking about which toe we should stand on. Well, good luck with that. I dust my feet of the whole affair. T.
On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote: > A comment about: RCR 14: Updated RCRchive > was sent by Gregory Brown. > > To send a comment, reply to this mail. Please trim all unnecessary > lines. > > You can view RCR 14 at: > https://rcrchive.net/rcrs/14 > > On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote: > > >Compared to Perl, Python, Erlang and even > > Rebol, Ruby's RCR process seems almost like a bad joke, which is > > really too bad b/c it has the potential to be better than any of > > those. > > Please consider discussing this privately. I think it's far outside > the scope of what the RCRchive is for. First you say it is boring on the Mailing List, now you say this is not the right place, well I do not know, Tom's made a lot of work and I feel that you are just harsh with him because of you do not like his POV, why did you vote neutral in that case? My impression is that indeed you do not like discussion and my impression is that posts like yours make some people think that some people are arrogant. That for sure is one of the worst things can happen to the community and it is much worse than any technical dispute... BTW I do not 100% agree with Tom's last post it was too radical, but what way to answer his honest opinions. I have said enough on this but I leave with frustration and please do not tell me that this is OT that I am frustrated... Robert
On 8/12/07, robert.dober@gmail.com <robert.dober@gmail.com> wrote: > I have said enough on this but I leave with frustration and please do > not tell me that this is OT that I am frustrated... I'm sorry, but it is. I know that we all want to be friends and we also want to get what we want and etc, etc, but I'm not in favour of taking a system designed for technical discussion and making it a forum for personal bickering. There is such a thing as personal mail, and it should be used for situations like this. If you'd like to discuss that point, feel free to contact me off list. It's not a matter of arrogance, but a matter of relevance.
On Aug 12, 2007, at 1:01 PM, transfire@gmail.com wrote: > On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> > wrote: >> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote: >>> Compared to Perl, Python, Erlang and even >>> Rebol, Ruby's RCR process seems almost like a bad joke, which is >>> really too bad b/c it has the potential to be better than any of >>> those. >> >> Please consider discussing this privately. I think it's far outside >> the scope of what the RCRchive is for. > > You know, I'm just not doing it anymore. You all can talk wherever you > all want. Every where I've turned with this I'm told to go else where. > If Ruby's own RCR process can't talk about Ruby's RCR process, then > for heaven's sake, do we need a MetaRCRrchive? I think that (albeit trolling) a discussion about how much Ruby does or does not suck, including Matz, or the change process - is appropriate for ruby-talk. A discussion about how to change the language, and the merits of that proposal, are appropriate for RCR. For any other RCR, I'd say that declarations about the poor state of Ruby or the RCR process would be inappropriate. However, for this meta-RCR about the process itself, it seems certainly valid to discuss whether or not the process is 'broken'. Part of that includes analyzing the process other languages are going through, and how well they work. So - Trans, what aspects of the Perl, Python, Erlang, or Rebol processes do you think work particularly well, and how do you think we should apply them to Ruby?
Hi -- Can people please take this to another forum? There are people subscribed to RCRs who really want to received mailings about proposed changes to the Ruby language, not about the RCR process. It would be best to find or create a forum (ruby-talk seems reasonable) for discussing the process, but meanwhile let the process, as it is now constituted, do what it's designed to do. Thanks -- David On Sun, 12 Aug 2007, phrogz@mac.com wrote: > A comment about: RCR 14: Updated RCRchive > was sent by Gavin Kistner. > > To send a comment, reply to this mail. Please trim all unnecessary > lines. > > You can view RCR 14 at: > https://rcrchive.net/rcrs/14 > > On Aug 12, 2007, at 1:01 PM, transfire@gmail.com wrote: >> On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> >> wrote: >>> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote: >>>> Compared to Perl, Python, Erlang and even >>>> Rebol, Ruby's RCR process seems almost like a bad joke, which is >>>> really too bad b/c it has the potential to be better than any of >>>> those. >>> >>> Please consider discussing this privately. I think it's far outside >>> the scope of what the RCRchive is for. >> >> You know, I'm just not doing it anymore. You all can talk wherever you >> all want. Every where I've turned with this I'm told to go else where. >> If Ruby's own RCR process can't talk about Ruby's RCR process, then >> for heaven's sake, do we need a MetaRCRrchive? > > I think that (albeit trolling) a discussion about how much Ruby does > or does not suck, including Matz, or the change process - is > appropriate for ruby-talk. > > A discussion about how to change the language, and the merits of that > proposal, are appropriate for RCR. > > For any other RCR, I'd say that declarations about the poor state of > Ruby or the RCR process would be inappropriate. However, for this > meta-RCR about the process itself, it seems certainly valid to > discuss whether or not the process is 'broken'. Part of that includes > analyzing the process other languages are going through, and how well > they work. > > So - Trans, what aspects of the Perl, Python, Erlang, or Rebol > processes do you think work particularly well, and how do you think > we should apply them to Ruby? >
My $.02 : I'd suggest that a 'half and half' solution be adopted:
better 'instructions' (only) on how to 'develop' an RCR. Specifically tell
people to post to the ruby language forum to ask for suggestions, then how
to use
http://rubygarden.org/Ruby/page/show/WouldntItBeNiceIf +
http://rubygarden.org/Ruby/page/show/RubyWishList +
http://rubygarden.org/Ruby/page/show/RcrFoundry
(if that's the best way).
The current instruction are good on how to submit a final draft. Most
people don't know that the others exist! Maybe a mailing list 'just' for
suggestions to the language would be nice, too. Anyway some sort of
documentation addition.
As to whether comments about good or badness belong in this mailing list--in
my opinion flaming stuff isn't necessarily good (i.e. opinions) but things
that could be implemented or what not would be good to discuss. I think
that making it better would help.
My own addition to the discussion is that it would be fun to be able to
'vote' on potential RCR's -- like if a lot of people want a certain
function...a poll would be interesting.
Just my $0.02
-Roger
On 8/23/07, rcrchive+14@rcrchive.net <rcrchive+14@rcrchive.net> wrote:
>
> Welcome to the comment list for:
>
> Updated RCRchive (RCR #14)
>
> This RCR was submitted by Trans Onoma,
> at Thu Aug 09 19:05:47 EDT 2007.
>
> There are earlier revisions of this RCR, at rcrchive. The one described
> here is the current version.
>
> To comment on this RCR, just reply to this message, using the Reply-To
> address. All commenting will be done via this email list.
>
> Please trim away this introductory message when you reply!
>
>
> This is a digest of all the comments, so far, on RCR 14,
> "Updated RCRchive". You'll be on the mailing list for all future
> comments. You can also add a comment by replying to this digest,
> but please trim it down!
>
>
> On Thu Aug 09 07:57:26 EDT 2007, Robert Dober said:
>
> Great initiative Tom.
> I completely support the idea, it seems even good enough to replace a
> Wiki, as the discussion page of the wiki would be replaced by comments
> like this.
> Thanks for taking the time and effort to jot this down.
> Robert
>
>
> ---------------------------------------------
>
> On Thu Aug 09 09:08:06 EDT 2007, Gregory Brown said:
>
> I support parts of this proposal.
>
> These are all good ideas:
>
> 1) Create a dedicated mailing list for RCR discussions, and adjust
> RCRchive to use this list instead of the multitude of lists it
> currently uses.
>
> 3) Add a 'development' status, that comes before 'pending'.
>
> This is less important to me:
>
> 4) Offer some standard procedures for the consideration process.
>
> This is not important at all to me:
>
> 2) Allow an RCRs to have multiple authors. Only authors can change an
> RCR, and add or remove other authors.
>
> 5) Have a design specialist, like John Long, take an afternoon or two
> cleaning-up and beautifying the site.
>
> I think that there is no problem with someone working with a few
> others to develop an RCR but ultimately I think one person should be
> responsible for maintaining it and seeing it through the process, just
> to limit administrative complexity.
>
> Also, on this meta RCR, a meta-meta comment, if there *were* to be
> some standard procedures, I'd recommend one to be that people don't
> use the RCRchive to reference personal issues. I can only respond to
> the following with 'who cares?'
>
> "As you surely know, I've been arguing many of these point for for
> some time. On occasion I have even become heated about it. This is
> simply because it is important to me. Dreaming about Ruby what-ifs
> (and what-ifs in general) is a hobby of mine"
>
> I mention this only because I feel like in the Analysis section of an
> RCR, perhaps you should be discussing the technical merits of an RCR
> and its effects, not the personal issues that it may have arised from.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 03:02:00 EDT 2007, Trans Onoma said:
>
> On 8/9/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote:
> > A comment about: RCR 14: Updated RCRchive
> > was sent by Gregory Brown.
> >
> > To send a comment, reply to this mail. Please trim all unnecessary
> > lines.
> >
> > You can view RCR 14 at:
> > https://rcrchive.net/rcrs/14
> >
> > I support parts of this proposal.
> >
> > These are all good ideas:
> >
> > 1) Create a dedicated mailing list for RCR discussions, and adjust
> > RCRchive to use this list instead of the multitude of lists it
> > currently uses.
> >
> > 3) Add a 'development' status, that comes before 'pending'.
> >
> > This is less important to me:
> >
> > 4) Offer some standard procedures for the consideration process.
> >
> > This is not important at all to me:
> >
> > 2) Allow an RCRs to have multiple authors. Only authors can change an
> > RCR, and add or remove other authors.
> >
> > 5) Have a design specialist, like John Long, take an afternoon or two
> > cleaning-up and beautifying the site.
> >
> > I think that there is no problem with someone working with a few
> > others to develop an RCR but ultimately I think one person should be
> > responsible for maintaining it and seeing it through the process, just
> > to limit administrative complexity.
>
> The Cut-based RCR was a joint project by myself and Peter
> Vanbroekhoven. We spent months editing it, and we would take turns
> working on it. It proved a very powerful way to work. It simply
> wouldn't have been as easy or turned out as well, had we non been able
> to do this (we used ruby garden wiki to accomplish this, btw). So I
> can understand, that it may not be priority #1. But it has value and
> really it shouldn't be hard to implement. RCRchive is a Rails app
> after all.
>
> > Also, on this meta RCR, a meta-meta comment, if there *were* to be
> > some standard procedures, I'd recommend one to be that people don't
> > use the RCRchive to reference personal issues. I can only respond to
> > the following with 'who cares?'
> >
> > "As you surely know, I've been arguing many of these point for for
> > some time. On occasion I have even become heated about it. This is
> > simply because it is important to me. Dreaming about Ruby what-ifs
> > (and what-ifs in general) is a hobby of mine"
> >
> > I mention this only because I feel like in the Analysis section of an
> > RCR, perhaps you should be discussing the technical merits of an RCR
> > and its effects, not the personal issues that it may have arised from.
>
> Point taken. I was only trying to emphasis the merits of my approach
> based on my dedication to the subject matter. I've reduced the
> statement a bit in my last update.
>
> I also think this proves the point about the 'development' status.
>
> T.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 10:24:56 EDT 2007, Gregory Brown said:
>
> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
>
> > The Cut-based RCR was a joint project by myself and Peter
> > Vanbroekhoven. We spent months editing it, and we would take turns
> > working on it. It proved a very powerful way to work. It simply
> > wouldn't have been as easy or turned out as well, had we non been able
> > to do this (we used ruby garden wiki to accomplish this, btw). So I
> > can understand, that it may not be priority #1. But it has value and
> > really it shouldn't be hard to implement. RCRchive is a Rails app
> > after all.
>
> I think that perhaps it would be reasonable to give more than one
> person *access* to refining an RCR while it is in development stage,
> but that once it is submitted, one person should own it. This is so
> that there would be a single point of contact for the core team and
> one person responsible for ultimately making sure the RCR makes it
> through the process properly.
>
> But with that in mind, I'm not entirely sure we need more software to
> do that. A dedicated mailing list for RCR discussion combined with
> ad-hoc wiki pages would probably solve the problem just fine without
> taking up David's time (or whoever is maintaining the RCRchive).
>
> > > I mention this only because I feel like in the Analysis section of an
> > > RCR, perhaps you should be discussing the technical merits of an RCR
> > > and its effects, not the personal issues that it may have arised from.
> >
> > Point taken. I was only trying to emphasis the merits of my approach
> > based on my dedication to the subject matter. I've reduced the
> > statement a bit in my last update.
>
> Unfortunately, I saw it as taking away from an otherwise reasonable
> request.
>
> > I also think this proves the point about the 'development' status.
>
> Yes. definitely.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 10:41:34 EDT 2007, David Black said:
>
> Hi --
>
> On Sun, 12 Aug 2007, gregory.t.brown@gmail.com wrote:
>
> > A comment about: RCR 14: Updated RCRchive
> > was sent by Gregory Brown.
> >
> > To send a comment, reply to this mail. Please trim all unnecessary
> > lines.
> >
> > You can view RCR 14 at:
> > https://rcrchive.net/rcrs/14
> >
> > On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
> >
> >> The Cut-based RCR was a joint project by myself and Peter
> >> Vanbroekhoven. We spent months editing it, and we would take turns
> >> working on it. It proved a very powerful way to work. It simply
> >> wouldn't have been as easy or turned out as well, had we non been able
> >> to do this (we used ruby garden wiki to accomplish this, btw). So I
> >> can understand, that it may not be priority #1. But it has value and
> >> really it shouldn't be hard to implement. RCRchive is a Rails app
> >> after all.
> >
> > I think that perhaps it would be reasonable to give more than one
> > person *access* to refining an RCR while it is in development stage,
> > but that once it is submitted, one person should own it. This is so
> > that there would be a single point of contact for the core team and
> > one person responsible for ultimately making sure the RCR makes it
> > through the process properly.
> >
> > But with that in mind, I'm not entirely sure we need more software to
> > do that. A dedicated mailing list for RCR discussion combined with
> > ad-hoc wiki pages would probably solve the problem just fine without
> > taking up David's time (or whoever is maintaining the RCRchive).
>
> The current arrangement is:
>
> * One mailing list per RCR.
> * Anyone on the mailing list for RCR x can edit RCR x.
> * All previous revisions are available.
> * Matz sees all of it.
>
> Whatever RCRchive does, there's always going to be the possibility of
> discussing and refining RCRs somewhere else, if you want to. It's
> literally impossible for RCRchive to subsume all possible discussion
> of changes to Ruby, and that never has been, and never will be, a
> goal.
>
> Also, just to reiterate an important point, RCRchive is strictly based
> on implementing a blueprint delivered by Matz. I'm not going to
> change it, unless I hear from Matz. So if I appear to be ignoring or
> stonewalling this discussion, that's why: there's no action required
> or even possible on my part based on general public discussion of what
> people think RCRchive should do.
>
> I would strongly recommend the "bend before you break" principle --
> meaning, just use email and wikis as needed and participate in the RCR
> process when you feel comfortable and ready to do so. ("You" meaning
> "everyone", not Greg specifically.)
>
>
> David
>
>
>
> ---------------------------------------------
>
> On Sun Aug 12 11:06:46 EDT 2007, Gregory Brown said:
>
> On 8/12/07, dblack@rubypal.com <dblack@rubypal.com> wrote:
>
> > I would strongly recommend the "bend before you break" principle --
> > meaning, just use email and wikis as needed and participate in the RCR
> > process when you feel comfortable and ready to do so. ("You" meaning
> > "everyone", not Greg specifically.)
>
> With that in mind, let me suggest something to Tom:
>
> Maybe all we need is an rcr-discuss google group?
>
> Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
> that solve the problem of overall discussion?
>
> Or if you feel like that's making it a second-class citizen... David,
> would you be willing to host an rcr-discuss mailing list at RCRchive?
> I'm not suggesting making any changes beyond that, but it' be a good
> place for this 'all in one' pre-discussion stuff.
>
> I'm generally not one to care much about formal process, I just want
> the RCR process to seem friendly and like it is effective. Maybe a
> small change like that would do so. It'd also give a place for Matz
> to participate in the pre-discussions if he wants without sifting
> through RubyTalk.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 12:43:42 EDT 2007, Robert Dober said:
>
> On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote:
> >
> >
> > With that in mind, let me suggest something to Tom:
> >
> > Maybe all we need is an rcr-discuss google group?
> >
> > Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
> > that solve the problem of overall discussion?
> >
> > Or if you feel like that's making it a second-class citizen... David,
> > would you be willing to host an rcr-discuss mailing list at RCRchive?
> > I'm not suggesting making any changes beyond that, but it' be a good
> > place for this 'all in one' pre-discussion stuff.
> >
> > I'm generally not one to care much about formal process, I just want
> > the RCR process to seem friendly and like it is effective. Maybe a
> > small change like that would do so. It'd also give a place for Matz
> > to participate in the pre-discussions if he wants without sifting
> > through RubyTalk.
> >
> Sounds pretty cool an idea, while I cannot talk for Tom I feel that
> this approach will allow us to identify the *real* needs of RCR.
> I appreciate the thinking work Tom has done, but to jump there would
> be an err optimistic approach.
> Gregory's idea seems a good idea for a first step.
> Maybe that first step will be enough, maybe it will lead us into a new
> direction, maybe a second step into the same direction will just
> follow, who knows?
>
> Let us try to find out :).
>
> Cheers
> Robert
>
>
>
>
> ---------------------------------------------
>
> On Sun Aug 12 13:49:29 EDT 2007, David Black said:
>
> Hi --
>
> On Sun, 12 Aug 2007, gregory.t.brown@gmail.com wrote:
>
> > A comment about: RCR 14: Updated RCRchive
> > was sent by Gregory Brown.
> >
> > To send a comment, reply to this mail. Please trim all unnecessary
> > lines.
> >
> > You can view RCR 14 at:
> > https://rcrchive.net/rcrs/14
> >
> > On 8/12/07, dblack@rubypal.com <dblack@rubypal.com> wrote:
> >
> >> I would strongly recommend the "bend before you break" principle --
> >> meaning, just use email and wikis as needed and participate in the RCR
> >> process when you feel comfortable and ready to do so. ("You" meaning
> >> "everyone", not Greg specifically.)
> >
> > With that in mind, let me suggest something to Tom:
> >
> > Maybe all we need is an rcr-discuss google group?
> >
> > Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
> > that solve the problem of overall discussion?
> >
> > Or if you feel like that's making it a second-class citizen... David,
> > would you be willing to host an rcr-discuss mailing list at RCRchive?
> > I'm not suggesting making any changes beyond that, but it' be a good
> > place for this 'all in one' pre-discussion stuff.
>
> I think you'll be better off with a Google group than anything hosted
> at RCRchive. Keep in mind, though, that there's no "all in one"
> possible; you can't stop other people from discussing Ruby changes
> anywhere else. The fact that Matz has commissioned a centralized
> site, and people are talking about creating alternatives, is proof of
> that :-)
>
> Besides, "pre" is in the mind of the beholder. I worry about every
> RCR evolving into a discussion about whether or not it was
> pre-discussed enough, etc.... rather than just discussed on its own
> merits.
>
> > I'm generally not one to care much about formal process, I just want
> > the RCR process to seem friendly and like it is effective. Maybe a
> > small change like that would do so. It'd also give a place for Matz
> > to participate in the pre-discussions if he wants without sifting
> > through RubyTalk.
>
> I've never heard him say that he wants a separate list or group for
> change discussions, and I've been dealing with him in detail about
> this for years. What he's said he wants is what I've tried to
> implement in RCRchive. That doesn't mean he'll never change the
> process, but as things stand, the process is in place.
>
> It would be good if someone could create whatever new forum is
> brewing, and then move this discussion there. I'd rather try to keep
> RCRchive itself focused on language change requests, and not itself.
>
>
> David
>
>
>
> ---------------------------------------------
>
> On Sun Aug 12 13:57:34 EDT 2007, Gregory Brown said:
>
> On 8/12/07, dblack@rubypal.com <dblack@rubypal.com> wrote:
>
> > I've never heard him say that he wants a separate list or group for
> > change discussions, and I've been dealing with him in detail about
> > this for years. What he's said he wants is what I've tried to
> > implement in RCRchive. That doesn't mean he'll never change the
> > process, but as things stand, the process is in place.
>
> This is a good point. The format we have here is what Matz wants,
> which I think is more important than what the community wants (at
> least for this purpose). Of course, if there was a huge backlash of
> folks wanting this to be changed, I think it'd be a different story.
> That doesn't seem to be the case though.
>
> > It would be good if someone could create whatever new forum is
> > brewing, and then move this discussion there. I'd rather try to keep
> > RCRchive itself focused on language change requests, and not itself.
>
> Sounds reasonable to me. I was mainly suggesting an alternative, not
> necessarily advocating that it should exist. (I've voted neutral on
> this request because it's exactly how I feel :)
>
> If someone wants to fire up a google group, just link it here and I'll
> follow you there, I suppose.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 14:21:54 EDT 2007, Trans Onoma said:
>
> On 8/12/07, robert.dober@gmail.com <robert.dober@gmail.com> wrote:
>
> > Sounds pretty cool an idea, while I cannot talk for Tom I feel that
> > this approach will allow us to identify the *real* needs of RCR.
> > I appreciate the thinking work Tom has done, but to jump there would
> > be an err optimistic approach.
> > Gregory's idea seems a good idea for a first step.
> > Maybe that first step will be enough, maybe it will lead us into a new
> > direction, maybe a second step into the same direction will just
> > follow, who knows?
> >
> > Let us try to find out :).
>
> I'm afraid it's not enough. I tried that a few years back with a
> 'ruby-muse' mailing list. It got a little traction but not enough to
> sustain itself. Sadly people would even down me and that list when I
> tried to drum up support for it. It simply wasn't officially endorsed
> by Matz or the core team, so few people cared. When were talking about
> an RCR process you have to have official support or it just won't fly.
> Unfortunately Matz seems pretty apathetic about the whole thing. I
> don't know why. I know there are certain people on the core team that
> are very arrogant, and don't give a hoot what anyone else thinks that
> isn't a grandmaster C coder. So maybe they are steering Matz away from
> a working RCR process. I don't know. But honestly, he might as well
> shut the whole thing down. Compared to Perl, Python, Erlang and even
> Rebol, Ruby's RCR process seems almost like a bad joke, which is
> really too bad b/c it has the potential to be better than any of
> those.
>
> http://dev.perl.org/perl6/rfc/
> http://www.python.org/dev/peps/
> http://www.erlang.org/eep.html *
> http://www.rebol.net/cgi-bin/r3blog.r
>
> T.
>
> * Erlang's looks exceptionally good. But I still think Ruby's could be
> even better.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 14:39:55 EDT 2007, Gregory Brown said:
>
> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
>
> >Compared to Perl, Python, Erlang and even
> > Rebol, Ruby's RCR process seems almost like a bad joke, which is
> > really too bad b/c it has the potential to be better than any of
> > those.
>
> Please consider discussing this privately. I think it's far outside
> the scope of what the RCRchive is for.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 15:01:49 EDT 2007, Trans Onoma said:
>
> On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote:
> > A comment about: RCR 14: Updated RCRchive
> > was sent by Gregory Brown.
> >
> > To send a comment, reply to this mail. Please trim all unnecessary
> > lines.
> >
> > You can view RCR 14 at:
> > https://rcrchive.net/rcrs/14
> >
> > On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
> >
> > >Compared to Perl, Python, Erlang and even
> > > Rebol, Ruby's RCR process seems almost like a bad joke, which is
> > > really too bad b/c it has the potential to be better than any of
> > > those.
> >
> > Please consider discussing this privately. I think it's far outside
> > the scope of what the RCRchive is for.
>
> You know, I'm just not doing it anymore. You all can talk wherever you
> all want. Every where I've turned with this I'm told to go else where.
> If Ruby's own RCR process can't talk about Ruby's RCR process, then
> for heaven's sake, do we need a MetaRCRrchive?
>
> You can tip toe on ice all you want, but if the ice is weak it's going
> to break. That's where this process is, ''-this close to oblivion, and
> you all are nitpicking about which toe we should stand on.
>
> Well, good luck with that.
>
> I dust my feet of the whole affair.
>
> T.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 15:24:34 EDT 2007, Robert Dober said:
>
> On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote:
> > A comment about: RCR 14: Updated RCRchive
> > was sent by Gregory Brown.
> >
> > To send a comment, reply to this mail. Please trim all unnecessary
> > lines.
> >
> > You can view RCR 14 at:
> > https://rcrchive.net/rcrs/14
> >
> > On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
> >
> > >Compared to Perl, Python, Erlang and even
> > > Rebol, Ruby's RCR process seems almost like a bad joke, which is
> > > really too bad b/c it has the potential to be better than any of
> > > those.
> >
> > Please consider discussing this privately. I think it's far outside
> > the scope of what the RCRchive is for.
>
> First you say it is boring on the Mailing List, now you say this is
> not the right place, well I do not know, Tom's made a lot of work and
> I feel that you are just harsh with him because of you do not like his
> POV, why did you vote neutral in that case?
>
> My impression is that indeed you do not like discussion and my
> impression is that posts like yours make some people think that some
> people are arrogant.
>
> That for sure is one of the worst things can happen to the community
> and it is much worse than any technical dispute...
>
> BTW I do not 100% agree with Tom's last post it was too radical, but
> what way to answer his honest opinions.
>
> I have said enough on this but I leave with frustration and please do
> not tell me that this is OT that I am frustrated...
>
> Robert
>
>
>
> ---------------------------------------------
>
> On Sun Aug 12 15:35:22 EDT 2007, Gregory Brown said:
>
> On 8/12/07, robert.dober@gmail.com <robert.dober@gmail.com> wrote:
>
> > I have said enough on this but I leave with frustration and please do
> > not tell me that this is OT that I am frustrated...
>
> I'm sorry, but it is. I know that we all want to be friends and we
> also want to get what we want and etc, etc, but I'm not in favour of
> taking a system designed for technical discussion and making it a
> forum for personal bickering.
>
> There is such a thing as personal mail, and it should be used for
> situations like this. If you'd like to discuss that point, feel free
> to contact me off list.
>
> It's not a matter of arrogance, but a matter of relevance.
>
>
> ---------------------------------------------
>
> On Sun Aug 12 16:35:38 EDT 2007, Gavin Kistner said:
>
> On Aug 12, 2007, at 1:01 PM, transfire@gmail.com wrote:
> > On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com>
> > wrote:
> >> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
> >>> Compared to Perl, Python, Erlang and even
> >>> Rebol, Ruby's RCR process seems almost like a bad joke, which is
> >>> really too bad b/c it has the potential to be better than any of
> >>> those.
> >>
> >> Please consider discussing this privately. I think it's far outside
> >> the scope of what the RCRchive is for.
> >
> > You know, I'm just not doing it anymore. You all can talk wherever you
> > all want. Every where I've turned with this I'm told to go else where.
> > If Ruby's own RCR process can't talk about Ruby's RCR process, then
> > for heaven's sake, do we need a MetaRCRrchive?
>
> I think that (albeit trolling) a discussion about how much Ruby does
> or does not suck, including Matz, or the change process - is
> appropriate for ruby-talk.
>
> A discussion about how to change the language, and the merits of that
> proposal, are appropriate for RCR.
>
> For any other RCR, I'd say that declarations about the poor state of
> Ruby or the RCR process would be inappropriate. However, for this
> meta-RCR about the process itself, it seems certainly valid to
> discuss whether or not the process is 'broken'. Part of that includes
> analyzing the process other languages are going through, and how well
> they work.
>
> So - Trans, what aspects of the Perl, Python, Erlang, or Rebol
> processes do you think work particularly well, and how do you think
> we should apply them to Ruby?
>
>
> ---------------------------------------------
>
> On Sun Aug 12 18:12:17 EDT 2007, David Black said:
>
> Hi --
>
> Can people please take this to another forum? There are people
> subscribed to RCRs who really want to received mailings about proposed
> changes to the Ruby language, not about the RCR process. It would be
> best to find or create a forum (ruby-talk seems reasonable) for
> discussing the process, but meanwhile let the process, as it is now
> constituted, do what it's designed to do.
>
> Thanks --
>
>
> David
>
> On Sun, 12 Aug 2007, phrogz@mac.com wrote:
>
> > A comment about: RCR 14: Updated RCRchive
> > was sent by Gavin Kistner.
> >
> > To send a comment, reply to this mail. Please trim all unnecessary
> > lines.
> >
> > You can view RCR 14 at:
> > https://rcrchive.net/rcrs/14
> >
> > On Aug 12, 2007, at 1:01 PM, transfire@gmail.com wrote:
> >> On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com>
> >> wrote:
> >>> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
> >>>> Compared to Perl, Python, Erlang and even
> >>>> Rebol, Ruby's RCR process seems almost like a bad joke, which is
> >>>> really too bad b/c it has the potential to be better than any of
> >>>> those.
> >>>
> >>> Please consider discussing this privately. I think it's far outside
> >>> the scope of what the RCRchive is for.
> >>
> >> You know, I'm just not doing it anymore. You all can talk wherever you
> >> all want. Every where I've turned with this I'm told to go else where.
> >> If Ruby's own RCR process can't talk about Ruby's RCR process, then
> >> for heaven's sake, do we need a MetaRCRrchive?
> >
> > I think that (albeit trolling) a discussion about how much Ruby does
> > or does not suck, including Matz, or the change process - is
> > appropriate for ruby-talk.
> >
> > A discussion about how to change the language, and the merits of that
> > proposal, are appropriate for RCR.
> >
> > For any other RCR, I'd say that declarations about the poor state of
> > Ruby or the RCR process would be inappropriate. However, for this
> > meta-RCR about the process itself, it seems certainly valid to
> > discuss whether or not the process is 'broken'. Part of that includes
> > analyzing the process other languages are going through, and how well
> > they work.
> >
> > So - Trans, what aspects of the Perl, Python, Erlang, or Rebol
> > processes do you think work particularly well, and how do you think
> > we should apply them to Ruby?
> >
>
>
>
> ---------------------------------------------
>
>
>
>
My $.02 : I'd suggest that a 'half and half' solution be adopted:<br>better 'instructions' (only) on how to 'develop' an RCR. Specifically tell people to post to the ruby language forum to ask for suggestions, then how to use
<br><br><a href="http://rubygarden.org/Ruby/page/show/WouldntItBeNiceIf">http://rubygarden.org/Ruby/page/show/WouldntItBeNiceIf</a> + <br><a href="http://rubygarden.org/Ruby/page/show/RubyWishList">http://rubygarden.org/Ruby/page/show/RubyWishList
</a> +<br><a href="http://rubygarden.org/Ruby/page/show/RcrFoundry">http://rubygarden.org/Ruby/page/show/RcrFoundry</a><br>(if that's the best way).<br>The current instruction are good on how to submit a final draft. Most people don't know that the others exist! Maybe a mailing list 'just' for suggestions to the language would be nice, too. Anyway some sort of documentation addition.
<br><br>As to whether comments about good or badness belong in this mailing list--in my opinion flaming stuff isn't necessarily good (i.e. opinions) but things that could be implemented or what not would be good to discuss. I think that making it better would help.
<br><br>My own addition to the discussion is that it would be fun to be able to 'vote' on potential RCR's -- like if a lot of people want a certain function...a poll would be interesting.<br>Just my $0.02<br>-Roger
<br><br><div><span class="gmail_quote">On 8/23/07, <b class="gmail_sendername"><a href="mailto:rcrchive+14@rcrchive.net">rcrchive+14@rcrchive.net</a></b> <<a href="mailto:rcrchive+14@rcrchive.net">rcrchive+14@rcrchive.net
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Welcome to the comment list for:<br><br> Updated RCRchive (RCR #14)<br>
<br>This RCR was submitted by Trans Onoma,<br>at Thu Aug 09 19:05:47 EDT 2007.<br><br>There are earlier revisions of this RCR, at rcrchive. The one described<br>here is the current version.<br><br>To comment on this RCR, just reply to this message, using the Reply-To
<br>address. All commenting will be done via this email list.<br><br>Please trim away this introductory message when you reply!<br><br><br>This is a digest of all the comments, so far, on RCR 14,<br>"Updated RCRchive". You'll be on the mailing list for all future
<br>comments. You can also add a comment by replying to this digest,<br>but please trim it down!<br><br><br>On Thu Aug 09 07:57:26 EDT 2007, Robert Dober said:<br><br>Great initiative Tom.<br>I completely support the idea, it seems even good enough to replace a
<br>Wiki, as the discussion page of the wiki would be replaced by comments<br>like this.<br>Thanks for taking the time and effort to jot this down.<br>Robert<br><br><br>---------------------------------------------<br><br>
On Thu Aug 09 09:08:06 EDT 2007, Gregory Brown said:<br><br>I support parts of this proposal.<br><br>These are all good ideas:<br><br>1) Create a dedicated mailing list for RCR discussions, and adjust<br>RCRchive to use this list instead of the multitude of lists it
<br>currently uses.<br><br>3) Add a 'development' status, that comes before 'pending'.<br><br>This is less important to me:<br><br>4) Offer some standard procedures for the consideration process.<br><br>This is not important at all to me:
<br><br>2) Allow an RCRs to have multiple authors. Only authors can change an<br>RCR, and add or remove other authors.<br><br>5) Have a design specialist, like John Long, take an afternoon or two<br>cleaning-up and beautifying the site.
<br><br>I think that there is no problem with someone working with a few<br>others to develop an RCR but ultimately I think one person should be<br>responsible for maintaining it and seeing it through the process, just<br>
to limit administrative complexity.<br><br>Also, on this meta RCR, a meta-meta comment, if there *were* to be<br>some standard procedures, I'd recommend one to be that people don't<br>use the RCRchive to reference personal issues. I can only respond to
<br>the following with 'who cares?'<br><br>"As you surely know, I've been arguing many of these point for for<br>some time. On occasion I have even become heated about it. This is<br>simply because it is important to me. Dreaming about Ruby what-ifs
<br>(and what-ifs in general) is a hobby of mine"<br><br>I mention this only because I feel like in the Analysis section of an<br>RCR, perhaps you should be discussing the technical merits of an RCR<br>and its effects, not the personal issues that it may have arised from.
<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 03:02:00 EDT 2007, Trans Onoma said:<br><br>On 8/9/07, <a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a> <<a href="mailto:gregory.t.brown@gmail.com">
gregory.t.brown@gmail.com</a>> wrote:<br>> A comment about: RCR 14: Updated RCRchive<br>> was sent by Gregory Brown.<br>><br>> To send a comment, reply to this mail. Please trim all unnecessary<br>> lines.
<br>><br>> You can view RCR 14 at:<br>> <a href="https://rcrchive.net/rcrs/14">https://rcrchive.net/rcrs/14</a><br>><br>> I support parts of this proposal.<br>><br>> These are all good ideas:<br>
><br>> 1) Create a dedicated mailing list for RCR discussions, and adjust<br>> RCRchive to use this list instead of the multitude of lists it<br>> currently uses.<br>><br>> 3) Add a 'development' status, that comes before 'pending'.
<br>><br>> This is less important to me:<br>><br>> 4) Offer some standard procedures for the consideration process.<br>><br>> This is not important at all to me:<br>><br>> 2) Allow an RCRs to have multiple authors. Only authors can change an
<br>> RCR, and add or remove other authors.<br>><br>> 5) Have a design specialist, like John Long, take an afternoon or two<br>> cleaning-up and beautifying the site.<br>><br>> I think that there is no problem with someone working with a few
<br>> others to develop an RCR but ultimately I think one person should be<br>> responsible for maintaining it and seeing it through the process, just<br>> to limit administrative complexity.<br><br>The Cut-based RCR was a joint project by myself and Peter
<br>Vanbroekhoven. We spent months editing it, and we would take turns<br>working on it. It proved a very powerful way to work. It simply<br>wouldn't have been as easy or turned out as well, had we non been able<br>to do this (we used ruby garden wiki to accomplish this, btw). So I
<br>can understand, that it may not be priority #1. But it has value and<br>really it shouldn't be hard to implement. RCRchive is a Rails app<br>after all.<br><br>> Also, on this meta RCR, a meta-meta comment, if there *were* to be
<br>> some standard procedures, I'd recommend one to be that people don't<br>> use the RCRchive to reference personal issues. I can only respond to<br>> the following with 'who cares?'<br>><br>
> "As you surely know, I've been arguing many of these point for for<br>> some time. On occasion I have even become heated about it. This is<br>> simply because it is important to me. Dreaming about Ruby what-ifs
<br>> (and what-ifs in general) is a hobby of mine"<br>><br>> I mention this only because I feel like in the Analysis section of an<br>> RCR, perhaps you should be discussing the technical merits of an RCR
<br>> and its effects, not the personal issues that it may have arised from.<br><br>Point taken. I was only trying to emphasis the merits of my approach<br>based on my dedication to the subject matter. I've reduced the
<br>statement a bit in my last update.<br><br>I also think this proves the point about the 'development' status.<br><br>T.<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 10:24:56 EDT 2007, Gregory Brown said:
<br><br>On 8/12/07, <a href="mailto:transfire@gmail.com">transfire@gmail.com</a> <<a href="mailto:transfire@gmail.com">transfire@gmail.com</a>> wrote:<br><br>> The Cut-based RCR was a joint project by myself and Peter
<br>> Vanbroekhoven. We spent months editing it, and we would take turns<br>> working on it. It proved a very powerful way to work. It simply<br>> wouldn't have been as easy or turned out as well, had we non been able
<br>> to do this (we used ruby garden wiki to accomplish this, btw). So I<br>> can understand, that it may not be priority #1. But it has value and<br>> really it shouldn't be hard to implement. RCRchive is a Rails app
<br>> after all.<br><br>I think that perhaps it would be reasonable to give more than one<br>person *access* to refining an RCR while it is in development stage,<br>but that once it is submitted, one person should own it. This is so
<br>that there would be a single point of contact for the core team and<br>one person responsible for ultimately making sure the RCR makes it<br>through the process properly.<br><br>But with that in mind, I'm not entirely sure we need more software to
<br>do that. A dedicated mailing list for RCR discussion combined with<br>ad-hoc wiki pages would probably solve the problem just fine without<br>taking up David's time (or whoever is maintaining the RCRchive).<br><br>
> > I mention this only because I feel like in the Analysis section of an<br>> > RCR, perhaps you should be discussing the technical merits of an RCR<br>> > and its effects, not the personal issues that it may have arised from.
<br>><br>> Point taken. I was only trying to emphasis the merits of my approach<br>> based on my dedication to the subject matter. I've reduced the<br>> statement a bit in my last update.<br><br>Unfortunately, I saw it as taking away from an otherwise reasonable request.
<br><br>> I also think this proves the point about the 'development' status.<br><br>Yes. definitely.<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 10:41:34 EDT 2007, David Black said:
<br><br>Hi --<br><br>On Sun, 12 Aug 2007, <a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a> wrote:<br><br>> A comment about: RCR 14: Updated RCRchive<br>> was sent by Gregory Brown.<br>><br>
> To send a comment, reply to this mail. Please trim all unnecessary<br>> lines.<br>><br>> You can view RCR 14 at:<br>> <a href="https://rcrchive.net/rcrs/14">https://rcrchive.net/rcrs/14</a><br>>
<br>> On 8/12/07, <a href="mailto:transfire@gmail.com">transfire@gmail.com</a> <<a href="mailto:transfire@gmail.com">transfire@gmail.com</a>> wrote:<br>><br>>> The Cut-based RCR was a joint project by myself and Peter
<br>>> Vanbroekhoven. We spent months editing it, and we would take turns<br>>> working on it. It proved a very powerful way to work. It simply<br>>> wouldn't have been as easy or turned out as well, had we non been able
<br>>> to do this (we used ruby garden wiki to accomplish this, btw). So I<br>>> can understand, that it may not be priority #1. But it has value and<br>>> really it shouldn't be hard to implement. RCRchive is a Rails app
<br>>> after all.<br>><br>> I think that perhaps it would be reasonable to give more than one<br>> person *access* to refining an RCR while it is in development stage,<br>> but that once it is submitted, one person should own it. This is so
<br>> that there would be a single point of contact for the core team and<br>> one person responsible for ultimately making sure the RCR makes it<br>> through the process properly.<br>><br>> But with that in mind, I'm not entirely sure we need more software to
<br>> do that. A dedicated mailing list for RCR discussion combined with<br>> ad-hoc wiki pages would probably solve the problem just fine without<br>> taking up David's time (or whoever is maintaining the RCRchive).
<br><br>The current arrangement is:<br><br> * One mailing list per RCR.<br> * Anyone on the mailing list for RCR x can edit RCR x.<br> * All previous revisions are available.<br> * Matz sees all of it.<br><br>Whatever RCRchive does, there's always going to be the possibility of
<br>discussing and refining RCRs somewhere else, if you want to. It's<br>literally impossible for RCRchive to subsume all possible discussion<br>of changes to Ruby, and that never has been, and never will be, a<br>goal.
<br><br>Also, just to reiterate an important point, RCRchive is strictly based<br>on implementing a blueprint delivered by Matz. I'm not going to<br>change it, unless I hear from Matz. So if I appear to be ignoring or
<br>stonewalling this discussion, that's why: there's no action required<br>or even possible on my part based on general public discussion of what<br>people think RCRchive should do.<br><br>I would strongly recommend the "bend before you break" principle --
<br>meaning, just use email and wikis as needed and participate in the RCR<br>process when you feel comfortable and ready to do so. ("You" meaning<br>"everyone", not Greg specifically.)<br><br><br>David
<br><br><br><br>---------------------------------------------<br><br>On Sun Aug 12 11:06:46 EDT 2007, Gregory Brown said:<br><br>On 8/12/07, <a href="mailto:dblack@rubypal.com">dblack@rubypal.com</a> <<a href="mailto:dblack@rubypal.com">
dblack@rubypal.com</a>> wrote:<br><br>> I would strongly recommend the "bend before you break" principle --<br>> meaning, just use email and wikis as needed and participate in the RCR<br>> process when you feel comfortable and ready to do so. ("You" meaning
<br>> "everyone", not Greg specifically.)<br><br>With that in mind, let me suggest something to Tom:<br><br>Maybe all we need is an rcr-discuss google group?<br><br>Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
<br>that solve the problem of overall discussion?<br><br>Or if you feel like that's making it a second-class citizen... David,<br>would you be willing to host an rcr-discuss mailing list at RCRchive?<br>I'm not suggesting making any changes beyond that, but it' be a good
<br>place for this 'all in one' pre-discussion stuff.<br><br>I'm generally not one to care much about formal process, I just want<br>the RCR process to seem friendly and like it is effective. Maybe a<br>small change like that would do so. It'd also give a place for Matz
<br>to participate in the pre-discussions if he wants without sifting<br>through RubyTalk.<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 12:43:42 EDT 2007, Robert Dober said:<br><br>On 8/12/07,
<a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a> <<a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a>> wrote:<br>><br>><br>> With that in mind, let me suggest something to Tom:
<br>><br>> Maybe all we need is an rcr-discuss google group?<br>><br>> Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would<br>> that solve the problem of overall discussion?<br>><br>> Or if you feel like that's making it a second-class citizen... David,
<br>> would you be willing to host an rcr-discuss mailing list at RCRchive?<br>> I'm not suggesting making any changes beyond that, but it' be a good<br>> place for this 'all in one' pre-discussion stuff.
<br>><br>> I'm generally not one to care much about formal process, I just want<br>> the RCR process to seem friendly and like it is effective. Maybe a<br>> small change like that would do so. It'd also give a place for Matz
<br>> to participate in the pre-discussions if he wants without sifting<br>> through RubyTalk.<br>><br>Sounds pretty cool an idea, while I cannot talk for Tom I feel that<br>this approach will allow us to identify the *real* needs of RCR.
<br>I appreciate the thinking work Tom has done, but to jump there would<br>be an err optimistic approach.<br>Gregory's idea seems a good idea for a first step.<br>Maybe that first step will be enough, maybe it will lead us into a new
<br>direction, maybe a second step into the same direction will just<br>follow, who knows?<br><br>Let us try to find out :).<br><br>Cheers<br>Robert<br><br><br><br><br>---------------------------------------------<br><br>
On Sun Aug 12 13:49:29 EDT 2007, David Black said:<br><br>Hi --<br><br>On Sun, 12 Aug 2007, <a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a> wrote:<br><br>> A comment about: RCR 14: Updated RCRchive
<br>> was sent by Gregory Brown.<br>><br>> To send a comment, reply to this mail. Please trim all unnecessary<br>> lines.<br>><br>> You can view RCR 14 at:<br>> <a href="https://rcrchive.net/rcrs/14">
https://rcrchive.net/rcrs/14</a><br>><br>> On 8/12/07, <a href="mailto:dblack@rubypal.com">dblack@rubypal.com</a> <<a href="mailto:dblack@rubypal.com">dblack@rubypal.com</a>> wrote:<br>><br>>> I would strongly recommend the "bend before you break" principle --
<br>>> meaning, just use email and wikis as needed and participate in the RCR<br>>> process when you feel comfortable and ready to do so. ("You" meaning<br>>> "everyone", not Greg specifically.)
<br>><br>> With that in mind, let me suggest something to Tom:<br>><br>> Maybe all we need is an rcr-discuss google group?<br>><br>> Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would<br>
> that solve the problem of overall discussion?<br>><br>> Or if you feel like that's making it a second-class citizen... David,<br>> would you be willing to host an rcr-discuss mailing list at RCRchive?<br>
> I'm not suggesting making any changes beyond that, but it' be a good<br>> place for this 'all in one' pre-discussion stuff.<br><br>I think you'll be better off with a Google group than anything hosted
<br>at RCRchive. Keep in mind, though, that there's no "all in one"<br>possible; you can't stop other people from discussing Ruby changes<br>anywhere else. The fact that Matz has commissioned a centralized
<br>site, and people are talking about creating alternatives, is proof of<br>that :-)<br><br>Besides, "pre" is in the mind of the beholder. I worry about every<br>RCR evolving into a discussion about whether or not it was
<br>pre-discussed enough, etc.... rather than just discussed on its own<br>merits.<br><br>> I'm generally not one to care much about formal process, I just want<br>> the RCR process to seem friendly and like it is effective. Maybe a
<br>> small change like that would do so. It'd also give a place for Matz<br>> to participate in the pre-discussions if he wants without sifting<br>> through RubyTalk.<br><br>I've never heard him say that he wants a separate list or group for
<br>change discussions, and I've been dealing with him in detail about<br>this for years. What he's said he wants is what I've tried to<br>implement in RCRchive. That doesn't mean he'll never change the
<br>process, but as things stand, the process is in place.<br><br>It would be good if someone could create whatever new forum is<br>brewing, and then move this discussion there. I'd rather try to keep<br>RCRchive itself focused on language change requests, and not itself.
<br><br><br>David<br><br><br><br>---------------------------------------------<br><br>On Sun Aug 12 13:57:34 EDT 2007, Gregory Brown said:<br><br>On 8/12/07, <a href="mailto:dblack@rubypal.com">dblack@rubypal.com</a> <
<a href="mailto:dblack@rubypal.com">dblack@rubypal.com</a>> wrote:<br><br>> I've never heard him say that he wants a separate list or group for<br>> change discussions, and I've been dealing with him in detail about
<br>> this for years. What he's said he wants is what I've tried to<br>> implement in RCRchive. That doesn't mean he'll never change the<br>> process, but as things stand, the process is in place.
<br><br>This is a good point. The format we have here is what Matz wants,<br>which I think is more important than what the community wants (at<br>least for this purpose). Of course, if there was a huge backlash of<br>folks wanting this to be changed, I think it'd be a different story.
<br>That doesn't seem to be the case though.<br><br>> It would be good if someone could create whatever new forum is<br>> brewing, and then move this discussion there. I'd rather try to keep<br>> RCRchive itself focused on language change requests, and not itself.
<br><br>Sounds reasonable to me. I was mainly suggesting an alternative, not<br>necessarily advocating that it should exist. (I've voted neutral on<br>this request because it's exactly how I feel :)<br><br>If someone wants to fire up a google group, just link it here and I'll
<br>follow you there, I suppose.<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 14:21:54 EDT 2007, Trans Onoma said:<br><br>On 8/12/07, <a href="mailto:robert.dober@gmail.com">robert.dober@gmail.com
</a> <<a href="mailto:robert.dober@gmail.com">robert.dober@gmail.com</a>> wrote:<br><br>> Sounds pretty cool an idea, while I cannot talk for Tom I feel that<br>> this approach will allow us to identify the *real* needs of RCR.
<br>> I appreciate the thinking work Tom has done, but to jump there would<br>> be an err optimistic approach.<br>> Gregory's idea seems a good idea for a first step.<br>> Maybe that first step will be enough, maybe it will lead us into a new
<br>> direction, maybe a second step into the same direction will just<br>> follow, who knows?<br>><br>> Let us try to find out :).<br><br>I'm afraid it's not enough. I tried that a few years back with a
<br>'ruby-muse' mailing list. It got a little traction but not enough to<br>sustain itself. Sadly people would even down me and that list when I<br>tried to drum up support for it. It simply wasn't officially endorsed
<br>by Matz or the core team, so few people cared. When were talking about<br>an RCR process you have to have official support or it just won't fly.<br>Unfortunately Matz seems pretty apathetic about the whole thing. I
<br>don't know why. I know there are certain people on the core team that<br>are very arrogant, and don't give a hoot what anyone else thinks that<br>isn't a grandmaster C coder. So maybe they are steering Matz away from
<br>a working RCR process. I don't know. But honestly, he might as well<br>shut the whole thing down. Compared to Perl, Python, Erlang and even<br>Rebol, Ruby's RCR process seems almost like a bad joke, which is<br>
really too bad b/c it has the potential to be better than any of<br>those.<br><br> <a href="http://dev.perl.org/perl6/rfc/">http://dev.perl.org/perl6/rfc/</a><br> <a href="http://www.python.org/dev/peps/">http://www.python.org/dev/peps/
</a><br> <a href="http://www.erlang.org/eep.html">http://www.erlang.org/eep.html</a> *<br> <a href="http://www.rebol.net/cgi-bin/r3blog.r">http://www.rebol.net/cgi-bin/r3blog.r</a><br><br>T.<br><br>* Erlang's looks exceptionally good. But I still think Ruby's could be
<br>even better.<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 14:39:55 EDT 2007, Gregory Brown said:<br><br>On 8/12/07, <a href="mailto:transfire@gmail.com">transfire@gmail.com</a> <<a href="mailto:transfire@gmail.com">
transfire@gmail.com</a>> wrote:<br><br>>Compared to Perl, Python, Erlang and even<br>> Rebol, Ruby's RCR process seems almost like a bad joke, which is<br>> really too bad b/c it has the potential to be better than any of
<br>> those.<br><br>Please consider discussing this privately. I think it's far outside<br>the scope of what the RCRchive is for.<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 15:01:49 EDT 2007, Trans Onoma said:
<br><br>On 8/12/07, <a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a> <<a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a>> wrote:<br>> A comment about: RCR 14: Updated RCRchive
<br>> was sent by Gregory Brown.<br>><br>> To send a comment, reply to this mail. Please trim all unnecessary<br>> lines.<br>><br>> You can view RCR 14 at:<br>> <a href="https://rcrchive.net/rcrs/14">
https://rcrchive.net/rcrs/14</a><br>><br>> On 8/12/07, <a href="mailto:transfire@gmail.com">transfire@gmail.com</a> <<a href="mailto:transfire@gmail.com">transfire@gmail.com</a>> wrote:<br>><br>> >Compared to Perl, Python, Erlang and even
<br>> > Rebol, Ruby's RCR process seems almost like a bad joke, which is<br>> > really too bad b/c it has the potential to be better than any of<br>> > those.<br>><br>> Please consider discussing this privately. I think it's far outside
<br>> the scope of what the RCRchive is for.<br><br>You know, I'm just not doing it anymore. You all can talk wherever you<br>all want. Every where I've turned with this I'm told to go else where.<br>If Ruby's own RCR process can't talk about Ruby's RCR process, then
<br>for heaven's sake, do we need a MetaRCRrchive?<br><br>You can tip toe on ice all you want, but if the ice is weak it's going<br>to break. That's where this process is, ''-this close to oblivion, and
<br>you all are nitpicking about which toe we should stand on.<br><br>Well, good luck with that.<br><br>I dust my feet of the whole affair.<br><br>T.<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 15:24:34 EDT 2007, Robert Dober said:
<br><br>On 8/12/07, <a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a> <<a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a>> wrote:<br>> A comment about: RCR 14: Updated RCRchive
<br>> was sent by Gregory Brown.<br>><br>> To send a comment, reply to this mail. Please trim all unnecessary<br>> lines.<br>><br>> You can view RCR 14 at:<br>> <a href="https://rcrchive.net/rcrs/14">
https://rcrchive.net/rcrs/14</a><br>><br>> On 8/12/07, <a href="mailto:transfire@gmail.com">transfire@gmail.com</a> <<a href="mailto:transfire@gmail.com">transfire@gmail.com</a>> wrote:<br>><br>> >Compared to Perl, Python, Erlang and even
<br>> > Rebol, Ruby's RCR process seems almost like a bad joke, which is<br>> > really too bad b/c it has the potential to be better than any of<br>> > those.<br>><br>> Please consider discussing this privately. I think it's far outside
<br>> the scope of what the RCRchive is for.<br><br>First you say it is boring on the Mailing List, now you say this is<br>not the right place, well I do not know, Tom's made a lot of work and<br>I feel that you are just harsh with him because of you do not like his
<br>POV, why did you vote neutral in that case?<br><br>My impression is that indeed you do not like discussion and my<br>impression is that posts like yours make some people think that some<br>people are arrogant.<br><br>
That for sure is one of the worst things can happen to the community<br>and it is much worse than any technical dispute...<br><br>BTW I do not 100% agree with Tom's last post it was too radical, but<br>what way to answer his honest opinions.
<br><br>I have said enough on this but I leave with frustration and please do<br>not tell me that this is OT that I am frustrated...<br><br>Robert<br><br><br><br>---------------------------------------------<br><br>On Sun Aug 12 15:35:22 EDT 2007, Gregory Brown said:
<br><br>On 8/12/07, <a href="mailto:robert.dober@gmail.com">robert.dober@gmail.com</a> <<a href="mailto:robert.dober@gmail.com">robert.dober@gmail.com</a>> wrote:<br><br>> I have said enough on this but I leave with frustration and please do
<br>> not tell me that this is OT that I am frustrated...<br><br>I'm sorry, but it is. I know that we all want to be friends and we<br>also want to get what we want and etc, etc, but I'm not in favour of<br>taking a system designed for technical discussion and making it a
<br>forum for personal bickering.<br><br>There is such a thing as personal mail, and it should be used for<br>situations like this. If you'd like to discuss that point, feel free<br>to contact me off list.<br><br>It's not a matter of arrogance, but a matter of relevance.
<br><br><br>---------------------------------------------<br><br>On Sun Aug 12 16:35:38 EDT 2007, Gavin Kistner said:<br><br>On Aug 12, 2007, at 1:01 PM, <a href="mailto:transfire@gmail.com">transfire@gmail.com</a> wrote:
<br>> On 8/12/07, <a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a> <<a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a>><br>> wrote:<br>>> On 8/12/07, <a href="mailto:transfire@gmail.com">
transfire@gmail.com</a> <<a href="mailto:transfire@gmail.com">transfire@gmail.com</a>> wrote:<br>>>> Compared to Perl, Python, Erlang and even<br>>>> Rebol, Ruby's RCR process seems almost like a bad joke, which is
<br>>>> really too bad b/c it has the potential to be better than any of<br>>>> those.<br>>><br>>> Please consider discussing this privately. I think it's far outside<br>>> the scope of what the RCRchive is for.
<br>><br>> You know, I'm just not doing it anymore. You all can talk wherever you<br>> all want. Every where I've turned with this I'm told to go else where.<br>> If Ruby's own RCR process can't talk about Ruby's RCR process, then
<br>> for heaven's sake, do we need a MetaRCRrchive?<br><br>I think that (albeit trolling) a discussion about how much Ruby does<br>or does not suck, including Matz, or the change process - is<br>appropriate for ruby-talk.
<br><br>A discussion about how to change the language, and the merits of that<br>proposal, are appropriate for RCR.<br><br>For any other RCR, I'd say that declarations about the poor state of<br>Ruby or the RCR process would be inappropriate. However, for this
<br>meta-RCR about the process itself, it seems certainly valid to<br>discuss whether or not the process is 'broken'. Part of that includes<br>analyzing the process other languages are going through, and how well<br>
they work.<br><br>So - Trans, what aspects of the Perl, Python, Erlang, or Rebol<br>processes do you think work particularly well, and how do you think<br>we should apply them to Ruby?<br><br><br>---------------------------------------------
<br><br>On Sun Aug 12 18:12:17 EDT 2007, David Black said:<br><br>Hi --<br><br>Can people please take this to another forum? There are people<br>subscribed to RCRs who really want to received mailings about proposed<br>changes to the Ruby language, not about the RCR process. It would be
<br>best to find or create a forum (ruby-talk seems reasonable) for<br>discussing the process, but meanwhile let the process, as it is now<br>constituted, do what it's designed to do.<br><br>Thanks --<br><br><br>David
<br><br>On Sun, 12 Aug 2007, <a href="mailto:phrogz@mac.com">phrogz@mac.com</a> wrote:<br><br>> A comment about: RCR 14: Updated RCRchive<br>> was sent by Gavin Kistner.<br>><br>> To send a comment, reply to this mail. Please trim all unnecessary
<br>> lines.<br>><br>> You can view RCR 14 at:<br>> <a href="https://rcrchive.net/rcrs/14">https://rcrchive.net/rcrs/14</a><br>><br>> On Aug 12, 2007, at 1:01 PM, <a href="mailto:transfire@gmail.com">
transfire@gmail.com</a> wrote:<br>>> On 8/12/07, <a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a> <<a href="mailto:gregory.t.brown@gmail.com">gregory.t.brown@gmail.com</a>><br>>> wrote:
<br>>>> On 8/12/07, <a href="mailto:transfire@gmail.com">transfire@gmail.com</a> <<a href="mailto:transfire@gmail.com">transfire@gmail.com</a>> wrote:<br>>>>> Compared to Perl, Python, Erlang and even
<br>>>>> Rebol, Ruby's RCR process seems almost like a bad joke, which is<br>>>>> really too bad b/c it has the potential to be better than any of<br>>>>> those.<br>>>><br>
>>> Please consider discussing this privately. I think it's far outside<br>>>> the scope of what the RCRchive is for.<br>>><br>>> You know, I'm just not doing it anymore. You all can talk wherever you
<br>>> all want. Every where I've turned with this I'm told to go else where.<br>>> If Ruby's own RCR process can't talk about Ruby's RCR process, then<br>>> for heaven's sake, do we need a MetaRCRrchive?
<br>><br>> I think that (albeit trolling) a discussion about how much Ruby does<br>> or does not suck, including Matz, or the change process - is<br>> appropriate for ruby-talk.<br>><br>> A discussion about how to change the language, and the merits of that
<br>> proposal, are appropriate for RCR.<br>><br>> For any other RCR, I'd say that declarations about the poor state of<br>> Ruby or the RCR process would be inappropriate. However, for this<br>> meta-RCR about the process itself, it seems certainly valid to
<br>> discuss whether or not the process is 'broken'. Part of that includes<br>> analyzing the process other languages are going through, and how well<br>> they work.<br>><br>> So - Trans, what aspects of the Perl, Python, Erlang, or Rebol
<br>> processes do you think work particularly well, and how do you think<br>> we should apply them to Ruby?<br>><br><br><br><br>---------------------------------------------<br><br><br><br></blockquote></div><br>
<br>
Hi --
*Please* let's not revive this discussion here. You're free to take it
anywhere you like, but as I've said several times, it's not a Ruby
language change request and I don't want to use RCRchive bandwidth on
it and subject subscribers to off-topic discussions.
And please can we not meta-debate about whether I'm right? The
Internet is wide open, and if I do a little gate-keeping out of
courtesy to the people who have subscribed to the site I'm responsible
for, it really doesn't mean I'm censoring anyone or stifling free
speech or anything. There's lots of space to set up mailing lists and
wikis and so on.
By the way, you can vote on RCRs. That has always been part of the
process. Log into the site and go to an RCR and scroll down. If you
have problems with the process please write directly to me.
I should also reiterate that RCRchive is an implementation of features
requested by Matz, and I've always shown him all the instructions and
so forth for his approval. I don't mean to stonewall you on
suggestions about how the site should present the RCR process, but I'm
really not going to modify it except in consultation with Matz (who
may very well find your ideas worthwhile, but I have to hear it from
him; the site exists at his instigation and based on his plan for it).
David
On Thu, 23 Aug 2007, rogerpack2005@gmail.com wrote:
> A comment about: RCR 14: Updated RCRchive
> was sent by Roger Deloy Pack.
>
> To send a comment, reply to this mail. Please trim all unnecessary
> lines.
>
> You can view RCR 14 at:
> https://rcrchive.net/rcrs/14
>
> My $.02 : I'd suggest that a 'half and half' solution be adopted:
> better 'instructions' (only) on how to 'develop' an RCR. Specifically tell
> people to post to the ruby language forum to ask for suggestions, then how
> to use
>
> http://rubygarden.org/Ruby/page/show/WouldntItBeNiceIf +
> http://rubygarden.org/Ruby/page/show/RubyWishList +
> http://rubygarden.org/Ruby/page/show/RcrFoundry
> (if that's the best way).
> The current instruction are good on how to submit a final draft. Most
> people don't know that the others exist! Maybe a mailing list 'just' for
> suggestions to the language would be nice, too. Anyway some sort of
> documentation addition.
>
> As to whether comments about good or badness belong in this mailing list--in
> my opinion flaming stuff isn't necessarily good (i.e. opinions) but things
> that could be implemented or what not would be good to discuss. I think
> that making it better would help.
>
> My own addition to the discussion is that it would be fun to be able to
> 'vote' on potential RCR's -- like if a lot of people want a certain
> function...a poll would be interesting.
> Just my $0.02
> -Roger
>
> On 8/23/07, rcrchive+14@rcrchive.net <rcrchive+14@rcrchive.net> wrote:
>>
>> Welcome to the comment list for:
>>
>> Updated RCRchive (RCR #14)
>>
>> This RCR was submitted by Trans Onoma,
>> at Thu Aug 09 19:05:47 EDT 2007.
>>
>> There are earlier revisions of this RCR, at rcrchive. The one described
>> here is the current version.
>>
>> To comment on this RCR, just reply to this message, using the Reply-To
>> address. All commenting will be done via this email list.
>>
>> Please trim away this introductory message when you reply!
>>
>>
>> This is a digest of all the comments, so far, on RCR 14,
>> "Updated RCRchive". You'll be on the mailing list for all future
>> comments. You can also add a comment by replying to this digest,
>> but please trim it down!
>>
>>
>> On Thu Aug 09 07:57:26 EDT 2007, Robert Dober said:
>>
>> Great initiative Tom.
>> I completely support the idea, it seems even good enough to replace a
>> Wiki, as the discussion page of the wiki would be replaced by comments
>> like this.
>> Thanks for taking the time and effort to jot this down.
>> Robert
>>
>>
>> ---------------------------------------------
>>
>> On Thu Aug 09 09:08:06 EDT 2007, Gregory Brown said:
>>
>> I support parts of this proposal.
>>
>> These are all good ideas:
>>
>> 1) Create a dedicated mailing list for RCR discussions, and adjust
>> RCRchive to use this list instead of the multitude of lists it
>> currently uses.
>>
>> 3) Add a 'development' status, that comes before 'pending'.
>>
>> This is less important to me:
>>
>> 4) Offer some standard procedures for the consideration process.
>>
>> This is not important at all to me:
>>
>> 2) Allow an RCRs to have multiple authors. Only authors can change an
>> RCR, and add or remove other authors.
>>
>> 5) Have a design specialist, like John Long, take an afternoon or two
>> cleaning-up and beautifying the site.
>>
>> I think that there is no problem with someone working with a few
>> others to develop an RCR but ultimately I think one person should be
>> responsible for maintaining it and seeing it through the process, just
>> to limit administrative complexity.
>>
>> Also, on this meta RCR, a meta-meta comment, if there *were* to be
>> some standard procedures, I'd recommend one to be that people don't
>> use the RCRchive to reference personal issues. I can only respond to
>> the following with 'who cares?'
>>
>> "As you surely know, I've been arguing many of these point for for
>> some time. On occasion I have even become heated about it. This is
>> simply because it is important to me. Dreaming about Ruby what-ifs
>> (and what-ifs in general) is a hobby of mine"
>>
>> I mention this only because I feel like in the Analysis section of an
>> RCR, perhaps you should be discussing the technical merits of an RCR
>> and its effects, not the personal issues that it may have arised from.
>>
>>
>> ---------------------------------------------
>>
>> On Sun Aug 12 03:02:00 EDT 2007, Trans Onoma said:
>>
>> On 8/9/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote:
>>> A comment about: RCR 14: Updated RCRchive
>>> was sent by Gregory Brown.
>>>
>>> To send a comment, reply to this mail. Please trim all unnecessary
>>> lines.
>>>
>>> You can view RCR 14 at:
>>> https://rcrchive.net/rcrs/14
>>>
>>> I support parts of this proposal.
>>>
>>> These are all good ideas:
>>>
>>> 1) Create a dedicated mailing list for RCR discussions, and adjust
>>> RCRchive to use this list instead of the multitude of lists it
>>> currently uses.
>>>
>>> 3) Add a 'development' status, that comes before 'pending'.
>>>
>>> This is less important to me:
>>>
>>> 4) Offer some standard procedures for the consideration process.
>>>
>>> This is not important at all to me:
>>>
>>> 2) Allow an RCRs to have multiple authors. Only authors can change an
>>> RCR, and add or remove other authors.
>>>
>>> 5) Have a design specialist, like John Long, take an afternoon or two
>>> cleaning-up and beautifying the site.
>>>
>>> I think that there is no problem with someone working with a few
>>> others to develop an RCR but ultimately I think one person should be
>>> responsible for maintaining it and seeing it through the process, just
>>> to limit administrative complexity.
>>
>> The Cut-based RCR was a joint project by myself and Peter
>> Vanbroekhoven. We spent months editing it, and we would take turns
>> working on it. It proved a very powerful way to work. It simply
>> wouldn't have been as easy or turned out as well, had we non been able
>> to do this (we used ruby garden wiki to accomplish this, btw). So I
>> can understand, that it may not be priority #1. But it has value and
>> really it shouldn't be hard to implement. RCRchive is a Rails app
>> after all.
>>
>>> Also, on this meta RCR, a meta-meta comment, if there *were* to be
>>> some standard procedures, I'd recommend one to be that people don't
>>> use the RCRchive to reference personal issues. I can only respond to
>>> the following with 'who cares?'
>>>
>>> "As you surely know, I've been arguing many of these point for for
>>> some time. On occasion I have even become heated about it. This is
>>> simply because it is important to me. Dreaming about Ruby what-ifs
>>> (and what-ifs in general) is a hobby of mine"
>>>
>>> I mention this only because I feel like in the Analysis section of an
>>> RCR, perhaps you should be discussing the technical merits of an RCR
>>> and its effects, not the personal issues that it may have arised from.
>>
>> Point taken. I was only trying to emphasis the merits of my approach
>> based on my dedication to the subject matter. I've reduced the
>> statement a bit in my last update.
>>
>> I also think this proves the point about the 'development' status.
>>
>> T.
>>
>>
>> ---------------------------------------------
>>
>> On Sun Aug 12 10:24:56 EDT 2007, Gregory Brown said:
>>
>> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
>>
>>> The Cut-based RCR was a joint project by myself and Peter
>>> Vanbroekhoven. We spent months editing it, and we would take turns
>>> working on it. It proved a very powerful way to work. It simply
>>> wouldn't have been as easy or turned out as well, had we non been able
>>> to do this (we used ruby garden wiki to accomplish this, btw). So I
>>> can understand, that it may not be priority #1. But it has value and
>>> really it shouldn't be hard to implement. RCRchive is a Rails app
>>> after all.
>>
>> I think that perhaps it would be reasonable to give more than one
>> person *access* to refining an RCR while it is in development stage,
>> but that once it is submitted, one person should own it. This is so
>> that there would be a single point of contact for the core team and
>> one person responsible for ultimately making sure the RCR makes it
>> through the process properly.
>>
>> But with that in mind, I'm not entirely sure we need more software to
>> do that. A dedicated mailing list for RCR discussion combined with
>> ad-hoc wiki pages would probably solve the problem just fine without
>> taking up David's time (or whoever is maintaining the RCRchive).
>>
>>>> I mention this only because I feel like in the Analysis section of an
>>>> RCR, perhaps you should be discussing the technical merits of an RCR
>>>> and its effects, not the personal issues that it may have arised from.
>>>
>>> Point taken. I was only trying to emphasis the merits of my approach
>>> based on my dedication to the subject matter. I've reduced the
>>> statement a bit in my last update.
>>
>> Unfortunately, I saw it as taking away from an otherwise reasonable
>> request.
>>
>>> I also think this proves the point about the 'development' status.
>>
>> Yes. definitely.
>>
>>
>> ---------------------------------------------
>>
>> On Sun Aug 12 10:41:34 EDT 2007, David Black said:
>>
>> Hi --
>>
>> On Sun, 12 Aug 2007, gregory.t.brown@gmail.com wrote:
>>
>>> A comment about: RCR 14: Updated RCRchive
>>> was sent by Gregory Brown.
>>>
>>> To send a comment, reply to this mail. Please trim all unnecessary
>>> lines.
>>>
>>> You can view RCR 14 at:
>>> https://rcrchive.net/rcrs/14
>>>
>>> On 8/12/07, transfire@gmail.com <transfire@gmail.com> wrote:
>>>
>>>> The Cut-based RCR was a joint project by myself and Peter
>>>> Vanbroekhoven. We spent months editing it, and we would take turns
>>>> working on it. It proved a very powerful way to work. It simply
>>>> wouldn't have been as easy or turned out as well, had we non been able
>>>> to do this (we used ruby garden wiki to accomplish this, btw). So I
>>>> can understand, that it may not be priority #1. But it has value and
>>>> really it shouldn't be hard to implement. RCRchive is a Rails app
>>>> after all.
>>>
>>> I think that perhaps it would be reasonable to give more than one
>>> person *access* to refining an RCR while it is in development stage,
>>> but that once it is submitted, one person should own it. This is so
>>> that there would be a single point of contact for the core team and
>>> one person responsible for ultimately making sure the RCR makes it
>>> through the process properly.
>>>
>>> But with that in mind, I'm not entirely sure we need more software to
>>> do that. A dedicated mailing list for RCR discussion combined with
>>> ad-hoc wiki pages would probably solve the problem just fine without
>>> taking up David's time (or whoever is maintaining the RCRchive).
>>
>> The current arrangement is:
>>
>> * One mailing list per RCR.
>> * Anyone on the mailing list for RCR x can edit RCR x.
>> * All previous revisions are available.
>> * Matz sees all of it.
>>
>> Whatever RCRchive does, there's always going to be the possibility of
>> discussing and refining RCRs somewhere else, if you want to. It's
>> literally impossible for RCRchive to subsume all possible discussion
>> of changes to Ruby, and that never has been, and never will be, a
>> goal.
>>
>> Also, just to reiterate an important point, RCRchive is strictly based
>> on implementing a blueprint delivered by Matz. I'm not going to
>> change it, unless I hear from Matz. So if I appear to be ignoring or
>> stonewalling this discussion, that's why: there's no action required
>> or even possible on my part based on general public discussion of what
>> people think RCRchive should do.
>>
>> I would strongly recommend the "bend before you break" principle --
>> meaning, just use email and wikis as needed and participate in the RCR
>> process when you feel comfortable and ready to do so. ("You" meaning
>> "everyone", not Greg specifically.)
>>
>>
>> David
>>
>>
>>
>> ---------------------------------------------
>>
>> On Sun Aug 12 11:06:46 EDT 2007, Gregory Brown said:
>>
>> On 8/12/07, dblack@rubypal.com <dblack@rubypal.com> wrote:
>>
>>> I would strongly recommend the "bend before you break" principle --
>>> meaning, just use email and wikis as needed and participate in the RCR
>>> process when you feel comfortable and ready to do so. ("You" meaning
>>> "everyone", not Greg specifically.)
>>
>> With that in mind, let me suggest something to Tom:
>>
>> Maybe all we need is an rcr-discuss google group?
>>
>> Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
>> that solve the problem of overall discussion?
>>
>> Or if you feel like that's making it a second-class citizen... David,
>> would you be willing to host an rcr-discuss mailing list at RCRchive?
>> I'm not suggesting making any changes beyond that, but it' be a good
>> place for this 'all in one' pre-discussion stuff.
>>
>> I'm generally not one to care much about formal process, I just want
>> the RCR process to seem friendly and like it is effective. Maybe a
>> small change like that would do so. It'd also give a place for Matz
>> to participate in the pre-discussions if he wants without sifting
>> through RubyTalk.
>>
>>
>> ---------------------------------------------
>>
>> On Sun Aug 12 12:43:42 EDT 2007, Robert Dober said:
>>
>> On 8/12/07, gregory.t.brown@gmail.com <gregory.t.brown@gmail.com> wrote:
>>>
>>>
>>> With that in mind, let me suggest something to Tom:
>>>
>>> Maybe all we need is an rcr-discuss google group?
>>>
>>> Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
>>> that solve the problem of overall discussion?
>>>
>>> Or if you feel like that's making it a second-class citizen... David,
>>> would you be willing to host an rcr-discuss mailing list at RCRchive?
>>> I'm not suggesting making any changes beyond that, but it' be a good
>>> place for this 'all in one' pre-discussion stuff.
>>>
>>> I'm generally not one to care much about formal process, I just want
>>> the RCR process to seem friendly and like it is effective. Maybe a
>>> small change like that would do so. It'd also give a place for Matz
>>> to participate in the pre-discussions if he wants without sifting
>>> through RubyTalk.
>>>
>> Sounds pretty cool an idea, while I cannot talk for Tom I feel that
>> this approach will allow us to identify the *real* needs of RCR.
>> I appreciate the thinking work Tom has done, but to jump there would
>> be an err optimistic approach.
>> Gregory's idea seems a good idea for a first step.
>> Maybe that first step will be enough, maybe it will lead us into a new
>> direction, maybe a second step into the same direction will just
>> follow, who knows?
>>
>> Let us try to find out :).
>>
>> Cheers
>> Robert
>>
>>
>>
>>
>> ---------------------------------------------
>>
>> On Sun Aug 12 13:49:29 EDT 2007, David Black said:
>>
>> Hi --
>>
>> On Sun, 12 Aug 2007, gregory.t.brown@gmail.com wrote:
>>
>>> A comment about: RCR 14: Updated RCRchive
>>> was sent by Gregory Brown.
>>>
>>> To send a comment, reply to this mail. Please trim all unnecessary
>>> lines.
>>>
>>> You can view RCR 14 at:
>>> https://rcrchive.net/rcrs/14
>>>
>>> On 8/12/07, dblack@rubypal.com <dblack@rubypal.com> wrote:
>>>
>>>> I would strongly recommend the "bend before you break" principle --
>>>> meaning, just use email and wikis as needed and participate in the RCR
>>>> process when you feel comfortable and ready to do so. ("You" meaning
>>>> "everyone", not Greg specifically.)
>>>
>>> With that in mind, let me suggest something to Tom:
>>>
>>> Maybe all we need is an rcr-discuss google group?
>>>
>>> Wiki pages come a dime a dozen and could be drawn up ad-hoc. Would
>>> that solve the problem of overall discussion?
>>>
>>> Or if you feel like that's making it a second-class citizen... David,
>>> would you be willing to host an rcr-discuss mailing list at RCRchive?
>>> I'm not suggesting making any changes beyond that, but it' be a good
>>> place for this 'all in one' pre-discussion stuff.
>>
>> I think you'll be better off with a Google group than anything hosted
>> at RCRchive. Keep in mind, though, that there's no "all in one"
>> possible; you can't stop other people from discussing Ruby changes
>> anywhere else. The fact that Matz has commissioned a centralized
>> site, and people are talking about creating alternatives, is proof of
>> that :-)
>>
>> Besides, "pre" is in the mind of the beholder. I worry about every
>> RCR evolving into a discussion about whether or not it was
>> pre-discussed enough, etc.... rather than just discussed on its own
>> merits.
>>
>>> I'm generally not one to care much about formal process, I just want
>>> the RCR process to seem friendly and like it is effective. Maybe a
>>> small change like that would do so. It'd also give a place for Matz
>>> to participate in the pre-discussions if he wants without sifting
>>> through RubyTalk.
>>
>> I've never heard him say that he wants a separate list or group for
>> change discussions, and I've been dealing with him in detail about
>> this for years. What he's said he wants is what I've tried to
>> implement in RCRchive. That doesn't mean he'll never change the
>> process, but as things stand, the process is in place.
>>
>> It would be good if someone could create whatever new forum is
>> brewing, and then move this discussion there. I'd rather try to
Comments
from Robert Dober, Thu Aug 09 07:57:26 -0400 2007