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

Where should the package git URL point to? #4

Open
dandv opened this issue Dec 2, 2014 · 1 comment
Open

Where should the package git URL point to? #4

dandv opened this issue Dec 2, 2014 · 1 comment

Comments

@dandv
Copy link
Contributor

dandv commented Dec 2, 2014

package.js has a readme field that can point to an arbitrary Markdown file - great! We can point that to the Meteor-specific README for the package. That README is located in the meteor directory of the meteor-integration branch of our fork. (We shouldn't point to the original repo because we don't know if the author will merge).

The question is, where to point the git field of package.js? Where do we want users to land when they click "GitHub" (presumably to check the library's activity) and "Report Bugs"?

Users may not realize that the package is not primarily maintained by a Meteor dev.

The author's repo

Pros

  • user sees the real repo, with accurate star count
  • author gets notified
  • if author wasn't Meteor-friendly, users reporting issues there shows demand for Meteor

Cons

  • if the author wasn't fine with the integration, they might be antagonized / close the issues
  • Meteor-integration-specific issues may appear off-topic to the author; this can be mitigated by CC-ing one of the @MeteorPackaging/packagers (as the READMEs can in fact advise)

Our MeteorPackaging fork repo

Pros

  • we'll be notified when users create issues

Cons

  • user sees a repo with zero stars
  • we're artificially notified if users report library-specific (not integration-specific) issues
  • the author doesn't get notified; we'd have to proxy the issues

Workarounds

  • Have a README in our repo (where the "GitHub" link will land) that clearly states, "This is the Meteor packaging for XXX, head over there for anything but Meteor-specific issues", and don't PR this readme
@dandv
Copy link
Contributor Author

dandv commented Dec 2, 2014

Should we keep the fork repo around after the original authors accept the PR?

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

1 participant