3 ms·
> Of course, it’s the core team’s prerogative to run the project as they wish. The rest of us are, after all, freeloaders. But procedural transparency isn’
by traderjane 7y ago
> Of course, it’s the core team’s prerogative to run the project as they wish. The rest of us are, after all, freeloaders. But procedural transparency isn’t just a mechanism for gathering community feedback, nor is it bureaucratic foofaraw. It’s also a tool for convincing users, especially industry adopters, that Racket has procedures and values that are worthy of time & money commitments—that there is a “rule of law” that guides outcomes.
> I may be a visible user and fan of Racket—and even a teacher at Racket School—but I don’t have any influence on the direction of Racket. I think the Racket community is now big enough, however, that pulling off this kind of major change in Racket requires a stronger procedural foundation. The absence of this foundation is, in this fan’s opinion, a greater risk to the success of Racket2 than any technical hurdle.
- neilv 7y agoI disagree with that quoted bit about freeloaders. A lot of people have invested a lot of time and energy to building Racket and the community, over close to 20 years. I fully agree with the bits about transparency, and would add to that... The best outcome I can imagine from the recent would be if the leadership articulates unambiguously what I've been calling the "top-level requirements" that guide everything else in Racket. (I have a pretty good guess at the top-level requirements thus far, based on history. I'm also pretty sure that much of the user community still has mistaken ideas about that. Another reason for articulating these top-level requirements is that they might be changing now, as it seems a few things are changing.) After the top-level requirements, as a guide and to also let people know where they stand, then it would be good to have a well-considered model for whatever input (and possibly decision-making) is wanted from the non-leadership.