docs: add eleith as a contributor for infra#2069
Conversation
|
@docker-mailserver/maintainers please have a look whether you like this or not and tell me :) I think this could be a nice community addition. If you dislike it, let me know too :) |
|
@georglauterbach i was looking into this multiple times, too. I would appreciate adding this as it also honors people that contribute to docs and report bugs etc even without writing a single line of code. But i have two concerns:
|
Co-authored-by: Frederic Werner <[email protected]>
Co-authored-by: Frederic Werner <[email protected]>
I have removed the badge and added your suggestions. The badge should now not be updated (according to StackOverflow 😆 ).
Sadly IDK. My gut tells me the list grows very long, but I cannot image that no one thought about this... |
georglauterbach
added
area/documentation
meta/needs triage
Found some info on their website. Seems like people remove the contributors list from README if it grows heavily and move it into a separate CONTRIBUTORS.md and link to that file in the README. The bot/tool can then be configured in its config file to update the CONTRIBUTORS instead of README. If your changes work i'm fine with this but i want the opinion of a few others here too. Tagging them for review. |
wernerfred
requested review from
casperklein,
erik-wramner,
fbartels and
polarathene
Co-authored-by: Frederic Werner <[email protected]>
|
I don't have much input on this, other than I'm all for representing contributors better than git history alone. I do share the same concern with size on main README. It may also be noise in README history, so probably better to go with the I haven't looked into any options, but assume it can sort or give emphasis to "top" contributors from the community too as they should probably be prioritized if there's a large history of contributors. |
As far as i have seen it is only:
Looking at the Contributors of Github we have 200+ over the time so maybe using a separate file directly is the better approach instead of running this way and than having to refactor on some point |
That data seems to just be JSON, we could probably populate it with existing git history or github API on the repo stats, that could be scheduled for example by CI to automate and keep up to date, it doesn't require manual maintenance of the list. Likewise, sort order could be applied with that information if desirable. I would assume there is some sort of Github Action for performing that or similar already since it's a common enough feature (and has it's own spec in place). Using CI and populating with existing history can always be done later if someone cares strongly about it, doesn't have to block anything, those were just things that I thought other projects do to some extent with this feature 😅 |
|
I agree on directly using a <!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section -->and then parses the input and works with it. |
There was a problem hiding this comment.
This should use the CONTRIBUTORS.md from now on.
You need to create CONTRIBUTORS.md and paste the content there that was added by this bot.
As mentioned in my earlier comment this will certainly not work as it can only take what it has already rendered (it like the docs) so the next addition will at least regenerate the whole thing.
The CLI has options for this:
all-contributors init
all-contributors add
all-contributors check
all-contributors generate
where the bot only knows:
@all-contributors add
As doing this setup manually isn't probably worth the effort let's see what it generates and then decide.
Co-authored-by: Frederic Werner <[email protected]>
|
Imho ready to merge. Let's use this and add contributors via the bot from time to time. If we like the CONTRIBUTORS.md we can include a reference in docs as well as in main README.md before the next release. If something speaks against it we simply need to remove that file again. Thoughts? Next steps:
|
3 participants
Add @eleith as a contributor for infra.
This was requested by georglauterbach in this comment