There has to be a way to automate this

[frigginglorious]

For github in particular, It probably could be automated from an API.

Or has anyone tried to add a shell script that parses pages like the contributor page (eg https://github.com/kentcdodds/all-contributors/graphs/contributors) that updates and replaces a contributor table at the bottom of README.md?

Maybe not. Doing it that way would be hardly foolproof, and difficult to organize.

[kentcdodds]

The challenge with fully automating it is that you'd have trouble automating when someone posts a blogpost, gives a talk, is constructively reviewing a PR, or answering questions on Stack Overflow (just to name a few examples, not to mention the difficulty with telling the difference between a code contribution and a design/test contribution).

However, I think that we can make it easier to maintain this list and @jfmengels is working on that 👍

[chrissimpkins]

While I really hesitate to propose additional repository meta files, a JSON or YAML file spec could help here and tools could be built around it.

Ugh, did I just say that...

[kentcdodds]

I agree that a config spec would be nice. Here's a start maybe: all-contributors/cli#1

[chrissimpkins]

@kentcdodds @jfmengels looks like it is coming together already!

[jfmengels]

Trying to :)

[glasnt]

I think I might be able to help here :)

I've made a tool specifically for automating the collecting of contributors from the GitHub API, called octohatrack (article about the app).

The algorithm is fairly straight forward, but it takes a while to parse for larger repos.

I've also little apps that show how to get at least some of the contributors for Stackoverflow tags and Wikipedia posts under the LABHR, if that helps :)

The visualisation method that @leesdolphin and I have been working on at https://labhr.github.io/js-hatrack/ doesn't have as much visual differentiation as this version, but works on a binary code/non-coding method.

[kentcdodds]

Very cool @glasnt! Thanks for chiming in!

I just ran it on my more popular repo angular-formly and it came up with hundreds of contributors. Super cool!

I think the real challenge with a fully automated solution is as I stated earlier:

The challenge with fully automating it is that you'd have trouble automating when someone posts a blogpost, gives a talk, is constructively reviewing a PR, or answering questions on Stack Overflow (just to name a few examples, not to mention the difficulty with telling the difference between a code contribution and a design/test contribution).

I'm just not sure that we can go 100% automated. I think the best is to develop a tool as @jfmengels is working on to make it easier to generate the markdown, and then encourage contributors to add themselves (and their contributions) to the list.

[glasnt]

@kentcdodds

So that's always going to be a problem. The major hubs can be automated, but it's not going to pick up everyone.

You can have 'rss feed planets' and such, but there's no a lot that beats the maintainers actively attributing help.

The future work I have planned for hatrack is to automate the github hubs, and then have a manual addition process, specifically for acknowledgements outside of GitHub. I think having a CONTRIBUTORS page that feeds into that might be super useful, and your categorisation stuff on top makes it extra fancy :)

[chrissimpkins]

@glasnt Very cool project Katie. It seems that you've already given a good deal of thought to something that (to my knowledge) we haven't resolved which is how to bridge high contributor volume, mature projects to this specification. This will prove to be a challenge.

Anyone have thoughts about this? From what I understand about @jfmengels's tool, it will be perfect for moderated, semi-automated list generation for low contributor volume projects at any stage of the project history, and for all projects from early stages in the project history where you have the opportunity to build the list prospectively. How do more mature, higher volume projects that already have numerous previous contributors reach into their history to support the spec?

[jfmengels]

@glasnt Cool project!
I'm working on all-contributors/cli#1 (soon in the shelves), so any tool that can fetch contributor data and write it in the configuration file will work with my tool. So if we build tools that find contributors well (I don't know how effective @glasnt's project currently is at that), I think we can build a nice toolchain.
Please file issues on my repo if you think of cool/useful things :)

[burodepeper]

Hi there, just wanted to say hi! ; ) (hey Chris!)

Actually, I was looking into/for something like this, so yay! I have to look deeper in to what has already been said and done, but thus far I find the suggested things rather (visually) verbose, though I recognize that that is fully my own opinion.

I'm curious what you all think about the order in which contributors appear. I might have skimmed over some previous remarks, but automation doesn't really allow for the subtle nuances of "intrinsic value added to a project". Even more so when it comes to sources that are non-public or non-trivial; random conversations via chat/email, social-media attention, perhaps even a seemingly unrelated thing a friend mentions during a bar-crawl. It's a little off-topic, but what are your views on adding those people in the first place?

[kentcdodds]

@burodepeper, thanks for your interest in the spec! I think that as you read up on the spec and the comments here your feelings are shared :-) What you describe is basically the reason this spec was created.

[mbad0la]

@kentcdodds @frigginglorious @chrissimpkins @jfmengels , please have a look at this atom package i'm working on. This helps to automate the all-contributors-spec inside atom text editor.

[kentcdodds]

Very cool! Do you wanna add it to the README?