indeedeng / starfish

Run your own FOSS Contributor Fund - use Starfish to find eligible voters

Starfish

As of July 2023, this project is no longer being actively maintained by Indeed. We are immensely grateful for all the support and contributions from our community throughout the years.

While this repository will remain open and accessible, we will not be issuing updates, accepting pull requests, or addressing issues. It is crucial for users to know that the codebase will not receive security updates or patches. Thus, please use this project with caution as it might not be secure or up-to-date with the latest industry standards.

We encourage the open-source community to fork this project if continued development is desired. We hope that the project has been of use and will continue to be valuable in its current state.

Thank you once again for your support and understanding.

Because Your Open Source Contributors Are Stars!

This is a tool to:

• Parse a CSV of employee GitHub Ids
• Use those Ids, and the Github REST API, to check for open source contributions made by those employees between 2 specific dates
• Log out the ids of those employees (either GitHub Ids or another unique identifier you choose)

Starfish gives you the option of either using the default settings or making customizations.

Purpose

The purpose of this tool is to make it easy for you to run your own FOSS Contributor Fund

Creating a FOSS contributor fund at your company is a great way to help sustain the open source software your company depends on!

FOSS Funds are democratized - anyone who has contributed to open source in a given cycle gets to vote that cycle for the project they are excited about.
You can use Starfish to determine which of your employees are eligible to vote within a specific time range.

For More Info on what a FOSS Contributor Fund is, and how to start your own, Watch This Talk from FOSDEM or Read This Post on Indeed's Engineering Blog or This awesome article from Open Collective

Getting Started

Prerequisites

First, clone the repo to your computer, then navigate to the starfish folder and run npm ci.

• This project only runs on node version 16 or higher, node 18 is preferred.
• node -v, will show you which version of node you're using on your machine.
• If your node version is below 16, either update to a compatible version of node, or install and use nvm so that Starfish can use a compatible node version without affecting other applications on your system.

Next, make a .csv file with the GitHub Ids you're interested in checking, and, if desired, an "alternate id" to go with each

Q&A Time!

What do you mean "alternate id"?

I mean, if you normally identify your employees by some unique identifier- like an LDAP, their email, an employee id number, or even just their names- you can add that to the CSV so that your output is more useful to you. (For example, we find a list of the emails of every employee who's eligible to vote in the FOSS Fund that month to be really useful.)
If you decide not to use an 'alternate id', your list of eligible employees will just be a list of their GitHub ids.

Why CSV?

We found that an easy way to get GitHub ids from Indeed employees was through a Google form that automatically recorded their Indeed email. From that form, we got a Google Sheet with employee info that is easily exported as a CSV file. (Go to File, Download As, and then choose CSV.)

How do I make a CSV?

A CSV is just a file of comma-separated values, with a newline between each line. It looks like this:
My GitHub ID is:,Email Address
danisyellis,[email protected]
octocat,[email protected]
thisNameWillThrowAnErrorBecauseItIsNotARealGithubId,[email protected]

(Not all CSVs have a header, but Starfish does expect the first row of your CSV to be a header.)
You can create a CSV on your own by creating a file, giving it the file extension .csv, and making it look like the above example. Or, even if you're not using google forms to gather GitHub ids, you can still enter your data into a google sheet (one column per data field, one row per person) and download a CSV from that.

You may want to store multiple CSV files in a folder that's inside of Starfish, but not tracked by git, so we have set up ./CSVsToParse for you.

Then, get yourself GitHub authentication credentials.

Log in to GitHub and register a new personal access token (you can find this under Profile > Settings > Developer Settings > Personal access token > "Generate new token"). Fill the "Note" field with e.g. "Starfish" or another description. You don't need to select any scopes. (By default, a token is allowed read-only access to public information, and that's all Starfish needs). Click "Generate token". Copy the access token and store it as you will need it for the next step.

Next, Create a file named .env, copy the contents of the .env.template file into it, and add your values to the new file.

• Paste the access token into GITHUB_TOKEN.
• TIMEZONE allows you to specify which timezone Starfish should use to decide on which day a contribution happened.
  • The default is UTC, which works well for organizations with multiple locations. See the "Time zones" section for details.
• CSV_COLUMN_NUMBER_FOR_GITHUB_ID and CSV_COLUMN_NUMBER_FOR_ALTERNATE_ID should match the columns in the input file.
  • The CSV you input will be turned into an array, so the numbers for the CSV columns are zero-indexed.
  • For example, in the example CSV above, CSV_COLUMN_NUMBER_FOR_GITHUB_ID = "0" and CSV_COLUMN_NUMBER_FOR_ALTERNATE_ID = "1"
  • If you choose not to use an alternate id, you can put the same value in both fields.
• To filter out events for which the author is the owner of the repository, simply set IGNORE_SELFOWNED_EVENTS = "true"; otherwise leave it as IGNORE_SELFOWNED_EVENTS = "".
• By default, Starfish will return the name of anyone who has at least 1 qualifying contribution within the time period. If you'd like to use a different number, you can change MINIMUM_NUMBER_OF_CONTRIBUTIONS.
• GITHUB_IMPORTANT_EVENTS contains a default set of events for Starfish to check. You can edit this list. It must contain a comma-separated list of events.
  • By default, this tool checks for CommitCommentEvents, IssueCommentEvents, IssuesEvents, PullRequestEvents, PullRequestReviewEvents, and PullRequestReviewCommentEvents.
  • We do not look for PushEvents because those are usually used for personal projects, not actual open source contributions.
  • Starfish allows you to filter events based on the specific action taken. For example, you might want to count when a pull request is opened, but not when it is closed. To do that, the list of important events can include basic types (like "PullRequestEvent") or a specific action of a type (like "PullRequestEvent.closed"). You can list multiple actions for the same event type. Visit GitHub event types for more information.

Time zones

The TIMEZONE value must be one of the following:

• An empty string '' which means UTC (aka GMT), and which is the default
• The word 'local', which means the local time zone
• a value from the IANA Time Zone Database. If you use this option, it would normally be the time zone of the organization's main office, such as "America/Los_Angeles".

If for some reason you want the time to be a constant offset from UTC, you can say : "Etc/GMT+6", to mean UTC-0600. Note that positive values in the TIMEZONE string will result in negative UTC offsets (that is, West of UTC), while negative values will result in positive UTC offsets. This behavior is defined by IANA, not by us.

For example:

TIMEZONE=“Etc/GMT+6”

would output:

Users that contributed between December 1, 2020, 12:00 AM GMT-6 and December 15, 2020, 11:59 PM GMT-6

For further reading see the luxon time zone documentation and the List of tz values

To run:

In your terminal, type node index.js {date1} {date2} {path/to/CSVfile}.csv

In the above, any text inside of curly brackets {} means that you should put your own value in.
Dates should be written in ISO-8601 format. For example, April 1, 2019 should be entered as 2019-04-01.
Here's an example of what the terminal command could look like (I name my CSV files by date): node index.js 2020-10-01 2020-11-01 CSVsToParse/2020-11-01.csv

Tip: You can redirect the output to a file, if you like: node index.js {date1} {date2} {path/to/CSVfile} > {nameOfFileToCreate}.txt

Updating

From time to time, we'll be updating the Starfish code. You can get the newest code with git pull origin main. Just be sure to run npm ci when you do that, in case any node packages were updated.

Other Important Info

• Caveats: The GitHub Rest API only holds the most recent 300 events for each user. Also, events older than 90 days will not be included (even if the total number of events in the timeline is less than 300). So, if you're looking for contributions from 4 months ago, Starfish won't be able to find any. And if you are looking for contributions from 2 months ago, and one or more of your users is very active (300 events or more per month!), your result might not be completely accurate.

• Also, we know that there are many types of contributions to open source - not just code, and not just on GitHub. At Indeed, we have a Google form Indeedians can fill out to tell us about other contributions they've made. We recommend you do that as well.

• Lastly, if you're using Starfish we'd love to hear about it. What are you using Starfish for? Does it work well for you? You can leave us a comment over in the Discussions.

Changelog and Troubleshooting

Changelog

We recently created a Changelog over in Starfish's Discussions. If you're using Starfish, I'd recommend Subscribing to notifications for the Changelog. We'll be posting there when big changes happen like interesting new features and, most importantly, when security issues arise and get patched.

Troubleshooting

• If you ran Starfish previously, pulled in new code, and are now having problems, it's probably because we made some changes for version 2.0.0

  • Starfish 2.0.0 changes how we talk to GitHub's API, because the old way is now deprecated. When you pull in the latest code changes, you'll also want to look at these Instructions to get a Personal Access Token for the GitHub API. Then, change your .env to use that token, instead of OAuth credentials.
  • Also, the TIMEZONE_OFFSET environment variable has become TIMEZONE. You'll want to change that as well, and most likely change the value you're giving it, as explained here

• Whenever you pull in new code, Make sure to run npm ci to update node packages.

• If you are having other issues (For example, if you need help switching your local clone's default branch from master to main), check out the Changelog.

• If you get any other errors you can't fix please start a Discussion so we can help you get set up or fix any bugs we've missed in the code.

Contributing

Always feel free to help out! Read our contributing guide to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes.

Code of Conduct

Starfish is governed by the Contributor Covenant v 1.4.1.

License

Starfish is licensed under the Apache 2 License.

Maintainers

danisyellis and the rest of the Indeed Open Source team

starfish's Issues

add markdownLint as an npm package

Some devs working on Starfish use the VSCode markdownLint package and it was confusing that they were getting tons of linting errors. So I

1. fixed some of the linting errors in README.md and CONTRIBUTING.MD
2. added a few comments into the README

To make things more consistent, it would probably be best if the project had markdown linting included in it via an npm package for a markdownLint command-line interface.
I believe these are the steps:

1. Decide whether to use https://www.npmjs.com/package/markdownlint-cli or https://www.npmjs.com/package/markdownlint-cli2
   • The second one comes from the same dev who made the library and VS Code extension, so my first inclination would be to use that one. But the first one has a lot more downloads. So a little bit of research needs to be done before deciding. One way to decide could be using the one whose documentation makes more sense to you.
2. add it to Starfish as a dev dependency i.e. ( npm i -D markdownlint-cli2 )
3. I think the next step would be to create a markdownLint configuration file that turns off the rules that are currently being disabled in the README.
4. make sure it still lints cleanly

Add configuration option to allow custom lists of important events.

The function filterResponseForImportantEvents relies on a hard-coded lists of events that we believe are important. This list of events should be moved to a configuration option that allows the list of events to be customized. By way of example, our list of events specifically excludes PushEvent, but future users may want to include it.

The simplest version of this would be to add a new variable to the .env.template file:

• List of Important Events ([The,List,Of,Events,That,We,Predefine])

Update filterResponseForImportantEvents to use the new .env variable.

Add documentation to the README.md for using the new .env variable.

comment formatting is wrong - change # to // in .env.template

Currently, using # for comments is throwing errors, so let's change it to // which is correct

Make README comply with linting rules

When using the markdownlint extension in VSCode, a number of linting errors show up.
We should fix them at some point, or else change the rules to conform with anything we think should be different.

As a stopgap measure, could add the README to either Gitignore or the linter's ignore file.

Feature: Allow excluding projects with non-OSI approved licenses

I believe the GitHub API can return the license for a given repo. OSI runs a server that lists approved licenses (https://github.com/OpenSourceOrg/api/blob/master/doc/endpoints.md). For each contribution, I think we could determine the license for the associated repo, and see if that is in the (current) list of OSI approved licenses. If it is not, we could ignore that contribution as we consider whether this user has made a contribution.

This should be optional, controlled by a configuration setting, with the default of using the current behavior (not filtering based on OSI license).

Add support for Bitbucket

Currently, we only look at Github, it would be great to look at other places people make contributions too.

Streamline env variables

Let's do this after converting the repo to TypeScript

Right now, the defaults for our env variables aren't very standardized. Some are optional, some aren't, some can be blank, others can't, etc. We have numeric entries that must be present, but should be allowed to be zero and we have a string (TIMEZONE) that is totally optional, where "" is treated as if it's missing.
We may want to change some of them to use non-string true and false. It looks like this package would allow us to do that in an .env file https://www.npmjs.com/package/dotenv-parse-variables

Add alt text to images

Add alt text to images for better accessibility.

On Mac, starfish often gets intermittent errors fetching user data

Because starfish queues up all the user fetch requests at once, they all get sent to the operating system in quick succession. This doesn't seem to be a problem on linux, but macs can get overwhelmed with even a few hundred github ids. (From memory, I think it's an issue with the dns resolution.) We don't know if ms windows is affected.

The proper long-term solution is to switch to a network library like axios that offers rate-limiting. As a workaround for now, we can inject slight delays between each call (10ms should be enough).

Add More Error Handling

Add error handling.

Move some code so that tests don't hang and the code is more readable

Currently, all of the code is in one file index.js

We'll want to move most of the code to a new file called starfish.js and have both index.js and the tests require that file so that running the tests doesn't have the side effect of running the entire application.

Also, this separation will probably make the code more readable by making it more obvious where the code starts.

Add Support for GitLab

Currently, we only look at Github, it would be great to look at other places people make contributions too.

Switch test suite from Mocha to Jest

Starfish package-lock.json should refer to npmjs

Package-lock.json should refer to the public registry npmjs registry:
"resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.10.4.tgz"

Add a "Troubleshooting" Section to the README

Eliminate the section entitled NOTE FOR CURRENT STARFISH USERS - BREAKING CHANGES
It is a) non-accessible because all caps and b) very specific to a certain period of time.

Replace it with a section called troubleshooting which will say If you get _____ errors, you can fix it like this ______

Also add to the new Troubleshooting section a bit about the intermittent 404 errors and what we've done to solve them and let us know if they're still seeing it. EDIT: I decided not to do this because I think we've fixed the problem. Instead, I put a link to Discussions and asked people to open a discussion there if they get any other errors.

Add configuration options to allow filtering of self-owned repositories

Currently Starfish does not filter out events in personal repositories. Future users may want to exclude contributions into personal repositories (defined here as "any repository owned by the user who triggered the event"). We should add configuration options that allow future users to easily implement their own policies regarding where events will be counted.

The simplest version of this would be to:

Add a variable to the .env.template:

Filter Out Events In User-Owned Repos? (true or false, default to false)
Add a new filterEventsFor function that filters the events based off this variable.

Add documentation in the README for using this env variable.

Un-nest the functions inside of `starfish.js`

Currently, starfish.js is essentially one massively nested function.
This code would be more maintainable if the functions weren't all chained together, calling each other, one after the other. If we can un-nest that, it would also be easier to pass parameters around, so we could get rid of some or all of the globals.

Update project to use Node 12

Upgrade Starfish to use Node 12, Node 10 or above is required to use Prettier

Update README.md with Project Structure Information

It could be helpful for new contributors to have a Project Structure section in the README.md explaining the structure, like what each folder/file does.

Example: https://github.com/twilio-labs/open-pixel-art/blob/master/CONTRIBUTING.md

convert Starfish to TypeScript

The Indeed Engineering team is a big fan of TypeScript. In a lot of ways, it makes coding easier and helps you find bugs.
Therefore, we'd like to eventually convert Starfish from plain JavaScript to TypeScript.

Add functionality for a "opt-out" users list.

We have heard from a number of contributors that they do not wish to be part of the FOSS fund voting Slack channel. With that in hand, we could use a function that allows the entry of an "opt-out" list that would be compared to the full list of contributors, then it would return a revised list of contributors minus the "opt-out" folk. The list of opt-out users needs to be manageable as well, in case someone does want to jump back in.

Input opt-out users > Starfish runs & compares it's users master list to opt-out list > Returns a modified user list to use.

Extract the entire Contributing section of the README into a Contributing.MD

Now that it's gotten longer, it makes sense to make it a separate file. Plus, that's good practice for an open source project to have a Contributing.MD

The new file should contain everything that's currently in the “Contributing” section of the README, and probably nothing else.

The README should be left with the header that says Contributing and a new sentence mentioning that we welcome contributors and they should look at our CONTRIBUTING.MD for information and requirements, with a link to the file.

Change the array used to check for duplicate ids into a set (edited issue title to reflect the change we decided on)

When checking for duplicated IDs we push existing ids into an array:

starfish/index.js

Line 35 in dc651c8

let arrayOfGithubIds = [];

Changing the data structure to an object will allow for O(1) lookup time instead of O(n) having to look through the whole array to check which will speed up the process and scale a little better. It could also reduce/simply the logic needed to identify duplicated github ids.

integration tests/ more tests

Currently, we're testing some individual functions in starfish.test.js, and testing our dateTime logic in dates.test.js, but we'd like to have a more robust test suite, including an integration test that uses the 'tests'fixtures/test.csv file'

handle Github's API deprecation

we're getting emails that the way we're sending in our auth credentials (the Github API personal access tokens and OAuth app tokens) is deprecated and will stop working in July.

Here is an example of the GitHub email:

On February 7th, 2020 at 14:35 (UTC) your application (starfish) used its client_id and client_secret (with the User-Agent node-fetch/1.0 (+https://github.com/bitinn/node-fetch)) as part of a set of query parameters to access an endpoint through the GitHub API:
https://api.github.com/user/{usernumberhere}/events

Please use Basic Authentication instead as using OAuth credentials in query parameters has been deprecated.

Depending on your API usage, we'll be sending you this email reminder at most once every 3 days.
Just one URL that was accessed with a User-Agent combination will be listed in the email reminder, not all.
Visit https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters for more information.

Thanks,
The GitHub Team

And here are some notes from an email with Kevin about how to handle this:
when I was still blocked by rate limiting, I was able to work around that by passing the token that I configured in my .env file. Before calling fetch, I constructed a headers with Basic authentication[1]. I'm not sure why passing it as a URL parameter didn't work.
[1]
let headers = {
Authorization:
"Basic " +
Buffer.from(githubClientID + ":" + githubClientSecret).toString("base64")
};
...
fetch(url, {
method: "GET",
headers: headers
//credentials: 'user:passwd'
})

replace Moment.js with Luxon

Moment is in a semi-deprecated state now. They recommend using something else in most cases.
We've tried out Luxon a bit and like it, so we're looking to switch Starfish to use Luxon everywhere that we're currently using Moment.

If you take up this issue, be sure to update the README to reflect any changes you make to how a user should fill out the TIMEZONE env variable.

Provide default values for most configuration options

Rather than always requiring users to create environment variables for everything, I would propose:

• CSV_COLUMN_NUMBER_FOR_GITHUB_ID could default to 0
• CSV_COLUMN_NUMBER_FOR_ALTERNATE_ID could default to 0
• TIMEZONE could default to UTC
• GITHUB_IMPORTANT_EVENTS could default to some reasonable list

This would make it easier for users to try running starfish the first time. It would also avoid the need for tests to set up a bunch of environment variables that aren't directly relevant to the tests themselves.

Starfish: Change how timezone offset is passed in and handled

The way we are handling the config TIMEZONE_OFFSET may only work for time zones west of UTC+0, and is confusing in the sense that a UTC-06 offset is entered as a positive 06. Also, it doesn't currently allow for true timezones– instead, it only allows a constant offset from UTC.

We should probably rename the config variable to something like "TIMEZONE", and allow the values to be any named timezone or offset value that moment accepts. For example, "America/Los_Angeles", "-04", "+0630", or "JST".

The meaning would be: Contributions would be assigned to a day based on boundaries of midnight in the specified time zone.

April 2020-Update all dependencies

April 2020 - update all outdated dependencies, such as dotenv, mocha etc.

Add configuration options to allow filtering of employer-owned repositories

Currently Starfish does not filter out events in repositories owned by specific organizations. Future users may want to exclude contributions into repositories that their employer owns (key point - one employer may own many GitHub Organizations). We should add configuration options that allow future users to easily implement their own policies regarding where events will be counted.

The simplest version of this would be to:

Add a variable to the .env.template:

Filter Out Events From These Owners ([List,Of,Owners], default to an empty list)
Add a new filterResponseFor function that filters the events based off these variables.

Add documentation in the README for using this env variable.

The person taking this on may want to look at the IGNORE_SELFOWNED_EVENTS env variable and how it's used, because it's also filtering out a certain kind of event.

Convert default branch to be named 'main'

Now that GitHub has finalized their tooling and process for renaming the default branch, let's change 'master' to 'main'.
Some documentation here https://github.com/github/renaming

Make fetching and filtering more performant

(NOTE: I made this ticket a while ago, but performance/ amount of time Starfish takes to run has never been a problem for us at Indeed. I think a company would have to be checking an extremely large number of employees for this to matter. So I'm going to put this in the backlog. If someone wants to work on it, great, but I don't think it's a particularly useful change at the moment.)

Currently We:

1. ping the github API for a person's events
2. Look at the first page and keep only the events that are event types we care about
3. Do this for every page of event history that Github has (they hold up to 300 events at a time, 10 per page)
4. Now, we look through that array of events to see if one is in the correct time period, and stop looking when we find one.

However, there's no reason to look through all 30 pages of a person's events if an event on the first page meets both criteria

So, refactor the code to check for

1. event type
2. if it happened in the time range
   BEFORE fetching the next page. If those are both true, log the contributor's alternate id and move on to the next person.

Allow filtering based on action types within event types

Starfish currently can be configured to count contributions based on their event type, like "PullRequestEvent". It would be nice to further be able to count (or not count) those events based on the event action. For example, to include PullRequestEvent "closed" events but not "opened" events.

I would propose that the existing event type environment variable could be extended in a backward-compatible way. If only an event type is specified, that would mean that all action types would be included. But if the entry had both an event type and an event action, like "PullRequestEvent.opened", that would mean that only pull request open actions would be counted. Listing multiple action types for a given event type would treat them as connected by "OR", just as listing multiple event types are already connected with an implicit OR.

Add configuration options to allow filtering of self-owned or employer-owned repositories

Currently Starfish does not filter out events in personal repositories, or in repositories owned by specific organizations. Future users may want to exclude contributions into repositories that their employer owns (key point - one employer may own many GitHub Organizations), or contributions into personal repositories (defined here as "any repository owned by the user who triggered the event"). We should add configuration options that allow future users to easily implement their own policies regarding where events will be counted.

The simplest version of this would be to:

Add variables to the .env.template:

• Filter Out Events In User-Owned Repos? (true or false, default to false)
• Filter Out Events From These Owners ([List,Of,Owners], default to an empty list)

Add new filterResponseFor functions that filter the events based off these variables.

Add documentation in the README for using these env variables.

New major version because we've created a breaking change

We need a new major version. (i.e. from version 1.0.0 to version 2.0.0)
That will tell users that there's been a breaking change introduced (i.e., if they pull in the new code and don't change anything, Starfish won't run correctly anymore).

The breaking change was the commit that changed our GitHub API auth from using an OAauth app to using a Personal Access Token. So, I'd like the new major version to start with that commit.

Add configuration option to allow filtering by minimum number of contributions

So far, the default has been 1 contribution.
I'm going to add the ability to change that number so you can decide that only employees who contribute 2,3,4, etc. times get a specific perk.

Update README.md CSV section

Update the README.md CSV section. I did the setup and used VS Code as my IDE. I saw some weird things happen with the CSV, so would like more clarification on CSV setup.

test issue

testing mariner

Adding Table of Content to Readme.md

@danisyellis

The idea for Adding Table of Content to Readme.md to add additional enhancement and readability to the docs file.
Also hopping between the information will be quite ease

I would like to work on this issue.

Cheers,

Add More Tests

Add more tests.

Use conditional requests to avoid rate limiting problems

See this link for more info conditional requests: https://developer.github.com/v3/#conditional-requests
We could use either ETags or the If-Modified-Since header.

Making a conditional request and receiving a 304 response does not count against our rate limit, so it could help any rate limiting issues.
We (at Indeed) haven't seen a huge problem with this, but a larger org almost certainly would.

only ignore self-owned events if the project isn't used by others

So we added an env variable IGNORE_SELFOWNED_EVENTS which ignores an event if the author of the event is also the owner of the repo.
The intention of this is to ignore projects that are just someone's practice project that they're storing on GitHub.

I'd like to add another piece to this feature now:

Some percentage of self-owned repos are not simply practice projects, but instead are living open source projects that other people contribute to and use. Therefore, let's add a check that looks to see if this self-owned repo looks like it's a viable open source project and, if so, include it even though it's self-owned.

Implementation:

1. When a repo is self-owned, do a call to the GH API for repo info.
2. Then, calculate a score based on the info. The repo gets one point each for

• Not a fork of another repo
• Has a license
• Watchers > 2
• Stars > 1
• Forks > 2

3. Use the score to decide whether or not to count the contribution - if repoScore is > 3 {count this contribution} We might want to make the number 3 a default that's customizable by the user.
4. Add documentation to the README about this:

• explain that self-owned repos aren't counted unless they meet a score threshold
• explain how the score is calculated (the 5 things that we're checking and the default of 3)
• include a mention that if someone thinks we're using the wrong numbers or the wrong methodology they can start a GitHub discussion or submit a PR

For Starfish users and potential users: Until this is implemented, feel free to comment here if you have thoughts about how this feature should be implemented.

Remove hard-coding of github id column

Currently this project hardcodes the column from which we get the github id here:

starfish/index.js

Line 50 in dc651c8

arrayOfGithubIds.push(currentRow[1]);

We should allow the user to specify which line they get it from. I figured this out while trying to run with test data (copy and pasted from readme.md and using my own details and getting zero responses). Once I added a dummy first column, it worked. What tipped me off was the use of google forms which adds a first column which is a timestamp.

I'd be happy to work on this :)

EDIT: This is the line that hard-codes it:

starfish/index.js

Line 70 in dc651c8

let url = `https://api.github.com/users/${row[1]}/events?client_id=${githubClientID}&client_secret=${githubClientSecret}`

Use fs.readFileSync instead of process.stdin to read CSV file

Change the code to use argv to get the filename of the CSV and then pass it in to readFileSync. This will replace the current code which expects the CSV contents to be piped in via stdin.

This will be less confusing to people reading the code because it's more standard.

Consolidate to a single .gitignore in the root directory

We currently have a second .gitignore file in CSVsToParse. While that works, it is a bit unusual to have subtree .gitignore files. Plus, we have to then have a line in that .gitignore telling it not to ignore .gitignore itself. It seems cleaner to just get rid of the extra .gitignore file, and have all of the ignore rules in the main .gitignore file in the root directory.

Set up linting

Linting will provide a way for contributors to make PRs with more confidence that they are meeting the coding standards of the project. This is easy to setup, but should probably be done by someone who is heading up the project so that we can adhere to their rules/style preferences.