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

Standardize authorship attribution #198

Closed
OriolAbril opened this issue Jul 31, 2021 · 3 comments · Fixed by #239
Closed

Standardize authorship attribution #198

OriolAbril opened this issue Jul 31, 2021 · 3 comments · Fixed by #239
Labels

Comments

@OriolAbril
Copy link
Member

OriolAbril commented Jul 31, 2021

Right now it's not clear how authors of examples should claim authorship so they can get proper credit. There are several alternatives around:

We could even use https://github.com/sloria/sphinx-issues with the user, pr roles to simplify linking to github users and relevant PRs if using approaches 1 or 3.

@OriolAbril
Copy link
Member Author

I propose to use option 3 with bullet points, like in https://pymc-examples.readthedocs.io/en/latest/survival_analysis/bayes_param_survival_pymc3.html. I think the dates are not necessary but don't hurt either. I propose to use the following categories:

  • Alice wrote: for notebooks created specifically for pymc-examples
  • Alice adapted Bob's blogpost: for notebooks adapted from blogposts. both authors and blogpost should be links to relevant places
  • Alice updated the notebook: basically for everything
  • Alice extended the notebook: (we could do without this one) for cases where someone adds new content to the notebook instead of making changes to improve the notebook without changing it's original intent. Updating could be a typo but could also be much more work than extending.
  • Alice *re-executed the notebook with PyMC3 x.y.z for rerunning the notebook without changes to code or text.

Main open question that comes to mind is if going forward we want those bullet points to link to the PR with the changes

@tjburch
Copy link
Contributor

tjburch commented Oct 13, 2021

@OriolAbril - Links to oriolabril.github.io in your original post all appear broken for me. But going off your explanation, I agree that option 3 is probably the best proposed. But some thoughts:

  • If you elect to keep a full log of progressive changes then it should go to the bottom. In your example there, scrolling past 6 bullet points before getting to the example is a bit annoying, and probably the typical person seeking an example doesn't care that much about who reran the notebook, they just want content. (Not to discredit the importance of these things, just the longer it is the more cumbersome it gets)
  • That being said, moving all of it to the end motivates the reader to leave before seeing who wrote it. If users never read the authorship, it's not great (if a tree falls in the forest and nobody is there to hear it, does it make a sound?)

If it were me, I'd basically do an amended version of 3 - put a list of contributors at the top:

Authored by john jacob jingleheimer schmidt, contributions from marie curie, albert einstein

Then make the bottom more akin to a changelog with the full description like you propose:

Revision log
Alice wrote: for notebooks created specifically for pymc-examples
Alice adapted Bob's blogpost: for notebooks adapted from blogposts. both authors and blogpost should be links to relevant places
Alice updated the notebook: basically for everything

That way people see contributors, but aren't overwhelmed with too much detail unless they want to look at the bottom.

Last:

Main open question that comes to mind is if going forward we want those bullet points to link to the PR with the changes

I don't see how this would hurt, only help, so I think you should.

@OriolAbril
Copy link
Member Author

I would prefer having a short and synthetic sentence at the top over duplicating info. Duplicating info is much harder to maintain and it quickly ends up containing different info in each place.

We could also try to get that on the left sidebar so it is easily available but doesn't "interfere" with reading the notebook 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants