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

feedback #2

Closed
hackergrrl opened this issue May 13, 2016 · 5 comments
Closed

feedback #2

hackergrrl opened this issue May 13, 2016 · 5 comments

Comments

@hackergrrl
Copy link
Contributor

some notes from me trying it:

  1. It might be worth mentioning that you'll need to run npm install -g yo as well -- that step wasn't immediately obvious to me. (might it be easier on end-users if it just made a cli called standard-readme?)
  2. I didn't expect this to write to readme.md for me, but it's cool that yo will ask to confirm and show diffs, etc.
  3. I get a ~5 second delay between running the command and seeing the first dialog. Probably not worth optimizing at this point, but it seems like a strangely long delay for such a program. Maybe inherited from yo?
  4. Nitpick: I'd like to see Y as a default for some of these 😉 -- possibly Background but almost certainly API.
  5. It'd be nice if License holder defaulted to maybe git config user.name as a decent predicate. Or maybe something more clever like fullname.

I like it! The interactive menus are attractive and allay any of my fears about forgetting about a field. Having the nice merge conflict options is nice to have as well. I also dig the paren-enclosed suggested defaults for some of the fields (like name).

@hackergrrl
Copy link
Contributor Author

Oh, one more: as per the spec the resulting file ought to be README.md, not readme.md ("Be called README.md (with capitalization).")

RichardLitt added a commit that referenced this issue May 14, 2016
@RichardLitt
Copy link
Owner

  1. Updated to add yo to the global install.
  2. Yep, that's how Yeoman works. Added note to usage.
  3. That's normal, it's a yeoman thing. I don't think that this is a problem; this is a rare event.
  4. I don't think that Background is necessary - for most libraries, it can be covered in the long description. I also don't think that API is always necessary - it is something that pertains to a lot of libraries, but certainly not everything. For instance, it doesn't pertain to this one, or to go-ipfs. Some frameworks won't need it, and I'm really hesitant to make it a must-have. I know where you're coming from, but this needs to work for other languages and tools - like CLI tools, which may not have the same needs and requirements - as publicly exported functions. Maybe open an issue in standard-readme?
  5. Yeah. That would be a cool thing to do. This was a fast job - there's some other stuff I want, too, like extra sections. Opened Automatically suggest use for license #3.
  6. Hmm. You know, I'm actually not sure that README vs. readme is important. Opened README vs. readme standard-readme#11

Glad you like it! Yeoman is pretty badass.

RichardLitt added a commit that referenced this issue May 14, 2016
@hackergrrl
Copy link
Contributor Author

hackergrrl commented May 14, 2016

Re 4: Maybe I miscommunicated -- I meant have these fields default to Yes, not making them must-haves / required.

@RichardLitt
Copy link
Owner

Ah! That's something to consider. Yeah, I think I can go for that.

@hackergrrl
Copy link
Contributor Author

I feel much less opinionated about these things now than I did once upon a time. Closing!

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

2 participants