Establish some written governance

[raggi]

This will need to evolve, this proposal is just a starting point based on history and practical concerns for invested stakeholders.

• For the time being, one of the stated project goals is to support the fuchsia command specification. This may change over time, but is a nod to our heritage and acknowledging this stakeholder helps us to make shared decisions. It's important to note that the Fuchsia command spec is not immovable, but it has its own governance model.
• We can support non-conflicting features beyond the aforementioned specification, and the library can enable users to write code that violates the aforementioned specification.
• We want to constrain the feature set in the library such that we maintain sight on several key goals:
  • small object code
  • low cost of ownership implementation
  • a balanced simple and easy to use public api surface

We should identify some key stakeholders to take part in decision making with regard to the above, and at a later time establish how that group membership evolves over time. The first implementation of the group will be discretionary.

Practical matters:

• There are a number of issues in the tracker, both open and closed the implementations of which have as yet been avoided due to apparent conflicts with the fuchsia command specification. We would like to respond to these thoughtfully, so the goal is to enable a mechanism by which we can make a project-local decision about which to accept and which to reject, while being considerate as discussed above. For now we'll label those issues as specification change issues, so that we can collate them for focused discussion at a dedicated time.
• Where applicable we will take back some of the suggestions to Fuchsia API council as change proposals for the fuchsia specification, as minimizing the deviation between available features in this library, and the specification to which the (current) largest user group is useful for both sides, as well as outside users who aren't clear on the relationship between the two. I'll take ownership of executing this process, but I'll also make sure to coordinate here so that all voices are heard - the process will be open.
• Some decisions have already been made by maintainers / stakeholders, but are not yet documented (particular those where the decision was not to support something). We will start to respond to issues requesting such features by adding documentation that explains the motivations behind the choice, even if that choice is just arbitrary. Requests to revisit those decisions will remain open, but the requester should bring new use cases / examples / motivations to the discussion.

[benbrittain]

Thanks for writing this up @raggi. I'm planning on taking some time and going through the existing issues/README in the near future and making it clear we are trending in this direction. We should have clear governance and mechanisms for contributing to Argh :)

I want argh to be maximally useful for everyone.

[dschuyler]

Just making a +1 note to "Fuchsia command spec is not immovable, but it has its own governance model" (above).

[sourcefrog]

It would be great to have some clarity on which features are in principle acceptable.

I think it's a real strength of Argh that it is opinionated and does not support every weird grammar, and the API is cleaner than structopt/Clap. But, in my opinion, it would be nice to support idiomatic Rust command lines as seen in Cargo.

#78, distinguishing arguments after --, is a good example of something that's common in Rust programs. (I don't know about Fuschia.)

If Argh wants to stick strictly to what is needed in Fuschia and no more, then perhaps there's room for a friendly fork that adds a few more features. On the other hand if you make clear that things like #78 are in principle acceptable and will get a reasonably timely review & release, people could help here.