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!

[asood123]

I love the idea of having people sign up their Github repo and building a waitlist.

Re: getting 10 people to commit before activating. Our backend isn't built for queued transactions. It does all transactions real-time. We could hack it:

1. And add a flag to Groups table onWaitlist that will determine what content to show on the frontend.
2. We'll still get the Stripe token and create a Donation with a flag toBeCharged (but not ping stripe to create a charge, customer, etc). Then, use a script to charge them for a particular group when we activate that group. Right way to do that would be a queuing system, which we'll need at some point anyway.

Ideally, we should be able to map fields from a github repo directly to our group page. Like first section of the README.md -> longDescription, etc.

Since the payments part is tricky, I'd get this live before implementing that piece. Allow the signup from our homepage, validate Github account, store in ConnectedAccounts, create the group in the background with the flag onWaitline and serve a static page "Your group isn't ready yet..." on opencollective.com/org/repo. That way the queue can start building, while we implement the payments piece.

[cuiki]

The second part I get: a state of the collective page where the applicant can share with their network to get backers on board. But where would the initial page/state live? The one where we outline the steps they need to follow to apply. I'm assuming in the OpenCollective landing page. Can you clarify?

[asood123]

Yep, we should link it off of our homepage. It's the website-static repo.
We can add you to it.
On Thu, Apr 21, 2016 at 2:20 PM Darío Muñoz notifications@github.com
wrote:

The second part I get: a state of the collective page where the applicant
can share with their network to get backers on board. But where would the
initial page/state live? The one where we outline the steps they need to
follow to apply. I'm assuming in the OpenCollective landing page. Can you
clarify?

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#33 (comment)

[xdamman]

Since we should eventually get rid of the static website repo I'd rather have that on the website repo and make sure we slowly but surely converge to the same footer and header and general style everywhere.
With a route like /opensource/apply

[erickrico]

Hey, on the step 3: Select the people who should be part of the collective (minimum 2)
the selected people need to have a OC account or they will be generated? I don't quite get this step

[xdamman]

They should be contributors of the github repo. We will automatically send them an email and they will have to accept the invitation (and they will become OC users if they weren't already)

[erickrico]

this is what i got so far, pretty much the main flow is done, each screen has more instances (ex: when nothing is selected, when only one member is added, etc)

[erickrico]

as for the instance of the collective trying to become a "real collective" we cant quite reuse the regular collective page, i think we can take queues but we have to create a different instance, this is what i propose in terms of information estructure

1- Introduction to the collective process (pending collective) and current status # of backers/ # of backers to become a collective

2- mission (it will look similar to the current collective headers)

3- Core Contributors & How they will spend the funds they get: here we will talk not only about the collective but also introduce what open collective does in terms of transparency, etc...

4- current backers in case there are any, and a cta to join the collective with the corresponding note about not getting charge until they become a "real collective"

[xdamman]

We should put ourselves in the shoes of the maintainer of an open source project. He will basically share that page to friends who already know what he/she is doing.

So in terms of hierarchy of information it should be:

h1 Help us create an open collective for MochaJS

We want to create an open collective to collect money from backers and sponsors for our open source project MochaJS. We will use that money to pay for design work, maintenance and servers.

We need at least 10 people to commit to become backers to be able to open our collective.

[ Be the [first|2nd|...] backer for $5/month ]
you won't be charged until we reach our goal of 10 backers

Thank you so much for your support.

-- Core contributor 1, Core Contributor 2, ...

h2 About Open Collective

We use [Open Collective host] to collect the funds on our behalf using OpenCollective. Whenever we need to use the money for something, we will submit the invoice or expense via the OpenCollective app and once approved we will be reimbursed. That way, you can always track our budget. Everything is transparent.

[piamancini]

I think it works. I agree that the most important thing is what they are
trying to do and the about OC comes next.

Also: are we gonna allow for user edit of that content?

[erickrico]

Hey im coming out with a concept of FOUNDERS for the first 10 backers, and we can add them a star or something on the backer card so they feel cool, give the people a urge for joining this pending collectives, kind of like a early bird. what do you think?

[xdamman]

Mmmm... I like that! "Be a founding backer". I wonder if there could be situations where people wouldn't want that the first 10 backers to be called that way. @piamancini what are your thoughts on this?

[piamancini]

I like it as well. My only caveat is that it can be tricky if it's misunderstood as founders of the project in itself. We already had one person raising concern about the "member since" in our public page and it makes sense.

[xdamman]

Yeah. Maybe there is a better name. Or maybe just the "member since" is enough to incentivize people to be a member asap?

[erickrico]

maybe we can just use the term "early bird" or just "early backer"

[erickrico]

Hey, check out the pending collective page, i will have to revisit a little the on-boarding final step (regarding mission and how they plan to spend the money) as for the logo on top i think it will be easy to get since we already got their github information and avatar of the repo owner... or just ask for it 😁

[xdamman]

Ship it!

I love it. I love the idea of the 10 cards. It's clear, it's simple, it's great.

[piamancini]

me too!!! love it

P.
piamancini.com
t: @piamancini
s: piamancini
OpenCollective https://opencollective.com

On Tue, Apr 26, 2016 at 8:13 PM, Xavier Damman notifications@github.com
wrote:

Ship it!

I love it. I love the idea of the 10 cards. It's clear, it's simple, it's
great.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#33 (comment)

[erickrico]

Just to recap, this will be the final version

[xdamman]

Actually now that I think more about this it would be better to by default show all contributors and ask the creator of the collective to uncheck the ones that shouldn't be members of the collective (instead of selecting the ones that should be part).
Maybe we can show a user card for each with their number of commits and last commit date.

[cuiki]

I agree with doing the uncheck vs the explicit selection. It'll be better for sure into helping having more contributors.

About the card including the commits and commit dates, that is cool, but what about contributors that are not engineers and work on the Open Source project? For example, I am in the GitHub organization of our projects, but since I am a designer, I don't do commits. Should we think of a way to elevate those cases too with a different card? Maybe it is just an edge case, but the other contributors cards will look cooler with the GH commits and all. I feel left out hahahaha

[xdamman]

That's a very good point.
We can probably add other metrics like number of comments. Let me see what data we can have through their API.

I'd love to also add the concept of "roles" at some point so that you could say "designer", or "community manager", etc. (not a title, I'm against titles)

[cuiki]

Yeah, I think roles are cool. I hate titles as well, but if we specify roles, it'll be cool. @erickrico, please wait for @xdamman to see what we can have through the API.

[erickrico]

cool, let me work on that step, i imagine a solution like the one on the "pick a repository" step but with checkboxes, any way let me get at it

[erickrico]

[xdamman]

Why not showing them as they would show on the page? So people already have an idea of the different size they will have (only the X most active contributors should have a full user card, the others should be smaller.) That way we could also reuse the same react component on the public page of the collective (there should just be a toggle "selectable") What do you think? Maybe it's more complicated this way to also convey how much they contributed? Maybe those stats can be "on hover"?

[erickrico]

hey, here is the mobile version + the bubble ( to reveal it on mobile you just tap the circle) i have an odd feeling about the stats in the bubble , i know we are focusing on the open-source community right now but how are we going to replicate this kind of information to the communities/organisations, i like the 1st contribution part because it can be mirrored as member since on the other kind of collectives, but the second part of last contribution doesn't feel quite right, what do you think?

[xdamman]

Instead of first and last commit I'd say "Contributor since ..." or "Contributor between 2013 and 2015".

How would the popover work for an avatar near the edge?

[erickrico]

[piamancini]

I like the idea! I wouldn't put the last day or the between. What if
someone starts contributing again? I say keep it simple and just put the
since date.

[xdamman]

In an open source project they are plenty of people who just contributed a tiny change 2 years ago. We should differentiate those from contributors who have been regularly active in the past 2 years.
Maybe the circle around them can reflect their level of contribution? (e.g. number of months they have been active)

[erickrico]

hey guys i think this issue is getting out of control, we feel confortable with the on-boarding process?
if so we can make a new issue regarding the contributors in the collective page.

[piamancini]

I agree. we need to move faster on this.

[erickrico]

oooo @xdamman i think i got it, we are going to order them by contribution relevance and show them this stats

dosnt really matter first and last commit, but the quality of each

[xdamman]

Yes, definitely good enough to already start the implementation. We can always iterate.

Ship it and please share progress.

[piamancini]

I like the solution you came up with!

[dasilvacontin]

I love these popovers – awesome job!

I know it no longer belongs to this 'ticket', but feel free to quote in whichever one you move the discussion to.

I would personally like to see issue/PR comments also reflected:

• There's peps that get very motivated helping people with issues that turn out to need no fix (OP didn't know how to use X feature, or didn't know it existed). This is very common in Mocha (and I personally prefer resolving questions on GitHub, since it's easier to find already-solved-questions through search than in Gitter, helps building a knowledge base).

  eg. @ScottFreeCode has been of great help lately without the need of contributing code. It would be a shame not to reflect that.

• There's also maintainers that, either due to preference or lack of time, focus mainly on doing code reviews and discussions. Not so common though, but still.

"Every comment is a contribution".

[carlosascari]

@erickrico, @asood123 defined the sign up through github flow here: #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
#33 (comment)

[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.