Skip to content
This repository has been archived by the owner on May 15, 2020. It is now read-only.

Update authorship and acknowledge past authors/maintainers #38

Open
star-szr opened this issue Mar 3, 2017 · 3 comments
Open

Update authorship and acknowledge past authors/maintainers #38

star-szr opened this issue Mar 3, 2017 · 3 comments
Labels

Comments

@star-szr
Copy link

star-szr commented Mar 3, 2017

Since this is now a community-maintained project, I think we should find a way to make the files in this project reflect that a bit better. I see that the READMEs have been updated to point to this repo which is a great step. What I'm proposing might be a bit controversial but at the same time, I think it would be respectful to not have Sorin's email all over the files in this project, including lines like this from the unarchive module:

Report bugs to <sorin.ionescu@gmail.com>.

Here's one staged proposal to take things further:

  1. First, create a list somewhere (possibly at the bottom of README.md or in a separate MAINTAINERS.md) of past maintainers. The reality is that as with any project, over time people will come and go. This list can act as a sort of "Hall of Fame". We could also list current maintainers :)
  2. Next, remove the references to authors from non-README files (leave references to authors in module READMEs for now). Specifically, many files have an author header which seems not very useful to me. Also, things like the "Report bugs" message mentioned above that will show up in command output.
  3. Next, consider removing authors from READMEs. Arguably, it's more important to know about maintainers in those files than the original authors.
@paulmelnikow
Copy link

Hi, thanks for your suggestion and interest in carrying this project forward.

We could recognize Sorin's extraordinary contributions, and also Robby's contributions, the origins of oh-my-zsh at Planet Argon, and Sorin's rationale in forking. It's important to recognize past and present authors and maintainers, and we could do a better job at this juncture. The readme updates merely direct users to the right place for support. That would be a nice bit of history to consolidate.

Github does a nice job automating the contributor list. Perhaps we could place that link somewhere prominent (currently it's in CONTRIBUTING.md).

@facastagnini facastagnini mentioned this issue Mar 4, 2017
5 tasks
@johnpneumann
Copy link

To quote myself on this (from #33)

Do you think the language here is a bit confusing (ex from modules/archive/README.md):

*The authors of this module should be contacted via the [issue tracker][1].*

  - [Sorin Ionescu](https://github.com/sorin-ionescu)

[1]: https://github.com/zsh-users/prezto/issues

I'm concerned that people will see the author and then end up back at the original repo instead of here. The flip-side of that is we'd need to get any submodule to update to the same thing (if consistency matters in this instance).

I think the latter point, matters less to me than having clarity.

A Foolish Consistency is the Hobgoblin of Little Minds
pep 8

I agree that having Sorins email on here may only increase the amount of people that continue to hit him up about things, however, I'm torn on how to do that. Putting something up at the top of the README with a link to the issues page here and providing a brief history of the project may help, but I also don't want to add unnecessary text. Open to thoughts and opinions on how best to handle this, but also don't want this to turn into bikeshedding.

@star-szr
Copy link
Author

star-szr commented Mar 8, 2017

Basically, I think tying authorship to "you must now support this forever" is problematic.

So I'm in favour of including less of this type of boilerplate overall, and when we need such boilerplate, directing folks to this issue tracker rather than specific people. That way it's not just one person handling all the bug reports, feature requests, etc.

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

No branches or pull requests

3 participants