Proposal: Create a standard process for proposals.

[bheads]

There does not seem to be a well defined and enforced process for language and library enhancements. The github issues seems a little crazy with them, and I have not been helping it as of late :). Many projects have a process for proposing enhancements (including process for the std lib) such as:

• Where proposals are posted.
• The format it should be in.
• The requirements of a proposal.
• The life cycle of the proposal, and tracking of
• Ownership
• How it gets accepted
• How it gets rejected
• And advertisement of the proposal process (wiki pages, links on the site, closing github issue and redirecting users?)

I know I am just a new comer (forum creeper) to zig, but there are a lot of things I am excited about with zig and I hope to be able to help with the std library. Process and administrative work can be a PITA but it does help with planning and organization in the long run. So is there interest in people like me in the community helpping the compiler/lib devs by doing paper work?

This proposal can also extend into a formal bug report process.

[bheads]

I updated ticket #985 (not as an advert of that, but) as a super rough example of what a proposal draft could look like.

[andrewrk]

The current setup is Benevolent Dictator For Life, with yours truly the Benevolent Dictator in question.

There is no process for proposals that will make everyone happy. So I'm going to pick one that makes most people happy, and myself happy.

Here it is:

It's all GitHub issues. Try to search for your issue/proposal before posting, but it's ok if you end up creating duplicate content. We'll figure it out together.

What makes a high quality proposal in Zig is the same thing that makes a high quality proposal anywhere. It's descriptive, has examples, has use cases, the proposer has tried to think about how it works with the overall picture in mind.

Life cycle is milestones. A milestone says when the issue/proposal will be either accepted and implemented, rejected, or postponed. You will notice that there are no issues without a milestone.

A proposal is accepted or rejected when all the considerations have been considered, and the BDFL (me), relying heavily on the information and opinions provided by everyone who participated in the proposal, decides that the matter is solved.

There is no concept of ownership. People are free to announce via any of the communication channels we have available that they are working on something in order to avoid clobbering work. In practice there are no problems with this.

In the Zen of Zig we have the philosophy,

Minimize energy spent on coding style.

This is so that we can maximize energy spent on the important stuff. This extends to meta-work such as GitHub issues as well. We don't nit-pick style or minor problems with the way people file issues. If there's a use case there, capture that. If the user puts a lot of issues in one, just go ahead and solve all of them.

I'm open to changing how this all works, but I'm satisfied with status quo. I don't think a formal proposals process is holding zig back. I think it's simply time available to people working on zig that is the bottleneck.

zig-lang team members, feel free to speak up and disagree with me.