Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta: Should this repo document current practice or point a good way to the future? #9

Closed
littledan opened this issue Nov 11, 2017 · 5 comments

Comments

@littledan
Copy link
Member

A few of the bugs (#3, #5, #6) point to ways that this proposal recommends doing things which don't seem to be done by the majority of proposal authors today. I see two ways to look at the purpose of this repository with respect to those issues:

  • This repository should document current practice, so that beginners can do things like existing proposals.
  • This repository should point a way to the future, documenting things that would be better than current practices.

I'm more inclined to the first goal for this repository: the idea would be to keep this repository's goals narrow, and pursue changes by convincing other committee members, then documenting the results. As things are now, it seems like this repository is following more like the second goal, where @ljharb is documenting different practices that are not followed by most repositories.

@domenic
Copy link
Member

domenic commented Nov 11, 2017

I am generally worried about this issue, but less than I thought I would be. In particular @ljharb hasn't wholesale ported some of his idiosyncratic preferences such as duplicating the spec in Markdown, which I'm glad about :). Of the issues you list, only #6 worries me. I liberally-license all my specs (or maybe I've forgotten a couple?) and I think that while we could perhaps point people to the auto-deploy setup, it's too much to ask if we're hoping this template's goal is to make things easier.

@ljharb
Copy link
Member

ljharb commented Nov 11, 2017

Lol yeah the markdown thing isn’t reasonable to ask people to do manually; if i can come up with a process to generate it from the ecmarkup, then I’d want to add that here (since it makes things more readable in-repo).

In general, i think it should be the second goal - documenting current practices is unnecessary since you can infer those from existing proposals. This repo is meant to look towards the future, not the past.

@littledan
Copy link
Member Author

I thought part of the point was that it was unclear what to infer from existing repos.

I've given some feedback on the patterns you are encouraging here; I'm wondering how you plan to gather more feedback so you can decide on what the recommendations should be.

@ljharb
Copy link
Member

ljharb commented Nov 13, 2017

I hope to gather more feedback by gradually asking for it from wider and wider circles, with the goal that changes aren't needed by the time it gets to a wide audience.

@ljharb
Copy link
Member

ljharb commented May 31, 2023

6 years later I think any feedback can continue to be filed as separate issues; the goal of this repo is to help new proposals, not current ones.

@ljharb ljharb closed this as completed May 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants