|Posted by Adam D Ruppe|
in reply to H. S. Teoh
Posted in reply to H. S. Teoh
On Thursday, 18 November 2021 at 23:19:20 UTC, H. S. Teoh wrote:
> OK, so the big question: who's "we"?
The international proletariat.
> And who are "we" negotiating with
The bourgeois class.
> and what specific result(s) are we after?
The dissolution of all class distinctions.
ok fine really it is anyone who wants to see real change in the language vs the leadership. And what want to see is the aforementioned change. Personally what I want is a new leadership structure, a steering group of probably seven, maybe eleven, selected by D stakeholders on some term basis, probably annually, who have authority to make whatever changes they see fit. From there, they guide the language.
Now, what I'd like to see from the steering group is:
1) A new DIP policy that dispenses with the pretensions of grandeur and focuses on getting things done. These aren't Ph.D. theses, they're ways to solicit use cases and associated feature requests and technical analyses from the community. The process I propose is letting the steering committee deliberate on them in a private forum thread, which is then made public (but read only) after the decision is locked. This decision can thus be reviewed without being bikeshedded to hell.
I would vote for steering committee members who weigh changes with a cost/benefit eye. Some breaking changes are short term pain for long term gain. That's worth it.
2) A radically different approach to Phobos development that is significantly more open than it is now. Phobos is currently where code goes to die. It should be where code goes to thrive among the community. Breaking changes are discouraged, but made when necessary.
I've heard people say the package manager renders the standard library obsolete, but this isn't really true. In fact, I think it might be the opposite: a strong stdlib gives a solid foundation for reliable and interoperable third party packages.
What I'd do is to curate things from the community that can be tested and adopted if need be. Then if there's multiple options, work with the authors to abstract out some common interface into Phobos and get the others to use them. Then other packages can depend on the Phobos interface as users swap out implementations.
But again, the steering group would have the final say. I'd just want them to create a process that can be reliably delegated so it isn't using any particular bottleneck; a decentralized development model of a centralized library. They'd say what they want then they can pull from community work if/when it pops up.
3) The steering group would also have access to the foundation budget for hiring outside consultants when necessary. While this might be programming work sometimes we'd more likely need outside help for things like marketing since we have significant in-house code talent.
But what I'd push for is the steering group reform specifically as a condition to stop the fork. The other details can be worked out once we have that formed. The steering group must have binding authority - if they decide a change is going to happen, it gets merged in and no individual can overrule that.