On boarding Open Source Projects

[xdamman]

We should have an easy process to on board open source repositories.

Apply to create an open collective for your open source project.

We are slowly accepting new open collectives. Apply today to reserve your spot.

1. Connect your github account
2. Select the repository for which you'd like to create an open collective (your repo needs to have at least 100 stars)
3. Select the people who should be part of the collective (minimum 2)
4. What's your mission?
5. What would use the money for?
6. Thank you for your application. To be eligible, you need to have at least 10 people to commit to become a backer or a sponsor. They won't be charged until your collective is approved. Share with them this link: opencollective.com/org/repo

   Pending collective

If a collective hasn't been approved yet, their page should say something along the lines of:

We have applied to become an open collective. To be approved, we need your help!

We need x more people to commit to become a backer or a sponsor.

Become a backer for $5/month Become a sponsor for $100/month You will only be charged once we reach our goal of 10 backers or sponsors

Thank you for your commitment. Help us spread the word!

[carlosascari]

@erickrico, @asood123 defined the sign up through github flow here: https://github.com/OpenCollective/OpenCollective/issues/81

It included a final step that has not been designed: Show thank you screen

[gr2m]

Hey I really love your work and thoughts on displaying the contributors of a project.

I understand that integrating tightly with GitHubs stats is tempting (e.g. how many contributions, time frames, etc), but from our experience it’s not always representative. There are many kinds of contributions that an open source project relies on that are not code, and it would be sad if they would not be worshiped.

If I understand correctly, the special meaning to "Core Contributors" at OpenCollective is that these people have access to the funds / or can approve reimbursements? I don’t think that this necessary need to be the same people as the ones who contributed to most code or anything else. At Hoodie we have different teams for Code, Design, Documentation, Editorial Work, and I could imagine to start another small team that is trusted by the community that are in charge for funds. Like overseeing reimbursements, budget plannings, outreach to potential sponsors, backers etc.

So long story short, I think it would be nice to keep this as flexible as possible. I’d like to add Contributors that did not contribute any code to the selected GitHub repository, and I’d like to freely select who of these should be in charge for approving reimbursements.

And altogether we should have a clear statement of how we plan to use the funds.

I hope what I’m saying makes any sense, I’m new to Open Collective <3

[piamancini]

@gr2m

There are many kinds of contributions that an open source project relies on that are not code, and it would be sad if they would not be worshiped.

I agree, and at the moment @boneskull is looking at how to bring this out of the github api. If you have any suggestions on how to automate brining in people who document, or merge & close issues. I'd be great. Since the person who makes the collective selects the contributors to onboard, they can easily do it. We could put a note in the flow that reminds them of this often overlooked contributions.

I’d like to freely select who of these should be in charge for approving reimbursements.

At this stage everyone can submit an expense and only hosts approve them. We need to work in the flow and 'admin' role that can approve expenses as well as the host.

And altogether we should have a clear statement of how we plan to use the funds.

Yes, maybe we can add this as clearly as now we have the mission statement.

[erickrico]

@asood123 hi, ascari just told me of a infinite loop when the user doesn't have a repo with 100+ stars, can we solve it with something like this, ( just a quick idea, not the final image or text)

[asood123]

That's a good solution. Nice work, @ericku. On Mon, May 23, 2016 at 7:18 PM Ericku notifications@github.com wrote:

hi, ascari just told me of a infinite loop when the user doesn't have a repo with 100+ stars, can we solve it with something like this, ( just a quick idea, not the final image or text) [image: screen shot 2016-05-23 at 6 14 56 pm] https://cloud.githubusercontent.com/assets/18429104/15487395/aa723808-2112-11e6-8d5c-f6b8d55b1b06.png

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/OpenCollective/OpenCollective/issues/33#issuecomment-221123947

[xdamman]

It's sad to see a sad face. Can we maybe make a star that is half filled? Or 100 stars with only x that are yellow and the remaining ones empty?

[erickrico]

quick update

and the link takes you to https://opencollective.com/opensource *fixed 😁

[piamancini]

nice work! i like this. one typo: is 'meantime'

[boneskull]

My tool/service will pull contributions in terms of commits for any given repo.

However, any other contribution which is not of the "commit" nature is not available if older than 90 days, or is above a 300-"event" cap (whichever comes first).

This is due to the limitations of the GitHub API and is not something we have control over. Circumventing the API through tools like screen-scrapers would almost surely be a violation of GitHub's TOS.

For example, if a relatively modest user of GitHub commented on several issues or created a few more within a 90-day span, we would get the full picture. But if a user uses GitHub all day, every day, we will quickly run up against the 300-event cap. An "event" is something that shows in the user's activity feed.

The best we can do is get what we can initially and store it, then add new activity to the store going forward.

The service will store raw data and do a limited amount of aggregation itself. Consumers of the service (e.g. the API and thus the website) can choose to exclude certain categories of activity (like issue comments or reactions), and/or "weight" the data as needed. Ideally these variables--which events are considered contributions and weighting--should be configurable per-collective.

[boneskull]

Another strategy might be to pull all issues and PRs for a repo, then aggregate the data that way. It might be difficult to know "where we left off" though.

Yet another is simply a hook that reports activity within a repo to the service in real-time, which it would then store. This may be easier to implement but more difficult to scale.

[xdamman]

What about pulling the git repository and run git-summary from TJ?

[boneskull]

@xdamman that's only going to give you commits. at any rate, the same result is available through the "List contributors" endpoint, so it's not necessary to do any cloning.