On boarding Open Source Projects about opencollective HOT 62 CLOSED

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 😁

from opencollective.

Just to recap, this will be the final version

from opencollective.

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

from opencollective.

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)

from opencollective.

I like the solution you came up with!

from opencollective.

quick update

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

from opencollective.

Ship it!

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

from opencollective.

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

from opencollective.

from opencollective.

ok, for the repo contributors, i think we should create a new kind of user, either organisations, communities and open-source projects can benefit from this, giving other kind of contributors acknowledge for their work towards the project, whiteout being called core contributors, since they are the guys who have direct access to the money (and other bigger responsibilities towards the collective).

For the name of this new entity i propose one of the following :

• Intellectual contributors
• soul contributors
• effort contributors.

and they will be displayed as the following sketch:

what do you think?

from opencollective.

from opencollective.

I love the way it looks :)

from opencollective.

This i great @erickrico!
And given that we now have "Core contributors" and "contributors", it makes sense to select the core ones and automatically add all contributors.

I wonder how this list of contributors would look on mobile and how you would do the hover state.
Also it would be good in that bubble to also show some stats, at least first and last contribution ("contributor between 2011 and 2013", "contributor since 2012", ...)

from opencollective.

Also: ship it! 🚢

from opencollective.

Sure, people should have different roles and responsibilities attached to it, but we should do our best to not convey the old paradigm of pyramid. A collective is people pursuing a mission together. Where each has something different to contribute. It should also be inviting. People should feel welcome to contribute whatever they can.

Tough design challenge!

from opencollective.

What do you think @piamancini ?

Also don't forget to add in the popover the first and last contribution as explained in my previous comment #33 (comment)

from opencollective.

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?

from opencollective.

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.

from opencollective.

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)

from opencollective.

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

from opencollective.

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

from opencollective.

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.

from opencollective.

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?

from opencollective.

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 [email protected]
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)

from opencollective.

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

from opencollective.

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

from opencollective.

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)

from opencollective.

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)

from opencollective.

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"

from opencollective.

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.

from opencollective.

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?

from opencollective.

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?

from opencollective.

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?

from opencollective.

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.

from opencollective.

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

from opencollective.

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

from opencollective.

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 [email protected]
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)

from opencollective.

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.

from opencollective.

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.

from opencollective.

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

from opencollective.

from opencollective.

i think to attack this issue properly I'll have to revisit the collective page, work there first and afterwards see how that translates to this step

from opencollective.

ok, keeping it simple, working on it

from opencollective.

hey, sooo this will be the new view for a collective,

core contributors + contributors (lots of contributors)

core contributors + contributors (few contributors)

and the actual on-boarding step

i did try a version with a ui more similar to the final result, but it seemed to crowded for a process that should be fast and concise

regarding the core contributors, i think we should put a limit to the number a oc should have, any notes on this?

from opencollective.

There is one thing bothering me though. There is this sense through this design that there is a pyramid. That the core contributors are above the contributors.

I'd love to see something more in circle or in network. Can you try something?

from opencollective.

yea, i do understand that it feels kind of segregating, let me try something out, but i do feel there must be some kind of hierarchy attached to the responsibilities they fulfill to the collective.

from opencollective.

challenge accepted!

from opencollective.

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?

from opencollective.

from opencollective.

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.

from opencollective.

from opencollective.

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

Ship it and please share progress.

from opencollective.

@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

from opencollective.

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

from opencollective.

@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)

from opencollective.

That's a good solution. Nice work, @ericku.
On Mon, May 23, 2016 at 7:18 PM Ericku [email protected] 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)

from opencollective.

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?

from opencollective.

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

from opencollective.

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.

from opencollective.

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.

from opencollective.

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

from opencollective.

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

from opencollective.