Hi, Avtar:

I took at look at their docs and presence on GitHub.  It looks well done,
and they seem responsive, but there are exactly two committers.  All
projects had to start somewhere, this might simply mean that they're doing
something new and better than other groups and it's just early days, but
it's something I would keep in mind once we get down to the ease of use,
features, etc.  and are narrowing down to a final candidate.

Cheers,


Tony

On 10 April 2018 at 20:46, Gill, Avtar <ag...@ocadu.ca> wrote:

> Do people have any mild, medium, or strong feelings about this project?
> https://colineberhardt.github.io/cla-bot/
>
> From the project's page:
>
> * The approved contributor list can be maintained in various ways
> including JSON files or a webhook
> * Provides a fully-hosted solution, you don't have to maintain your own
> bit installation
>
> Avtar
>
>
> -----Original Message-----
> From: Tirloni, Giovanni
> Sent: Tuesday, April 10, 2018 12:37 PM
> To: Justin Obara <obara.jus...@gmail.com>; Bates, Simon <sba...@ocadu.ca>
> Cc: Fluid Work <fluid-w...@fluidproject.org>; Gill, Avtar <ag...@ocadu.ca>;
> Harnum, Alan <ahar...@ocadu.ca>
> Subject: Re: CLA service for Fluid GitHub repos
>
> Hello,
>
> On one hand, cla-assistant introduces a new database for us (MongoDB). On
> the other, clahub is in Ruby and we have more people with JS knowledge. New
> database vs. New language. It's hard to say.
>
> Moving on to ecosystem analysis...
>
>   * clahub last commit was in Feb 2017 and they have 14 contributors.
>   * cla-assistant last commit was 3 hours ago and they have 30
> contributors. Besides SAP backing it, they have PRs from Microsoft too. A
> bunch of code coverage, test and dependency checks in their README.
>
> I'm thinking the cla-assistant project might be in better shape but I
> haven't tried to deploy either one.
>
> Regards,
> Giovanni
>
> On 04/10/2018 01:12 PM, Justin Obara wrote:
> > Thanks Simon,
> >
> > I wonder if Gio, Avtar, Alan or others might have thoughts on that.
> >
> > Thanks
> > Justin
> >
> > On April 4, 2018 at 10:53:21 AM, Bates, Simon (sba...@ocadu.ca <mailto:
> sba...@ocadu.ca>) wrote:
> >
> >> Something that we may want to take into consideration is the
> implementation language/technology (if we end up hosting an instance
> ourselves).
> >>
> >> cla-assistant is JavaScript Node.js with MongoDB for persistence
> >>
> >> and clahub is Ruby on Rails
> >>
> >> Simon
> >>
> >> ________________________________________
> >> From: fluid-work <fluid-work-boun...@lists.idrc.ocad.ca <mailto:
> fluid-work-boun...@lists.idrc.ocad.ca>> on behalf of Justin Obara <
> obara.jus...@gmail.com <mailto:obara.jus...@gmail.com>>
> >> Sent: April 3, 2018 3:35 PM
> >> To: Fluid Work
> >> Subject: CLA service for Fluid GitHub repos
> >>
> >> Hi everyone,
> >>
> >> We've been talking about simplifying the process of getting CLAs signed
> for some time now. Below I'll provide a summary of the current process as
> well as the two leading CLA service contenders. We'd really appreciate your
> feedback and suggestions on which approach to take. Also, if you have any
> question or would like further clarification on any part, please let me
> know.
> >>
> >> Thanks
> >> Justin
> >>
> >>
> >> Current Process - paper based
> >>
> >> * A contributor is directed to the Fluid Licensing<https://wiki.
> fluidproject.org/display/fluid/Fluid+Licensing#FluidLicensing-
> ContributorLicenseAgreements> wiki page to sign either the CLA or the CCLA
> >> * The contributor downloads the CLA or CCLA
> >> * The contributor fills out the CLA or CCLA and scans or faxes it back
> to the IDRC
> >> * We print off a copy of the CLA or CCLA and physically store it
> >>
> >> Current Process - paper based
> >>
> >> Our current process has been in place for many years now is essentially
> paper based.
> >>
> >> Process for a contributor
> >>
> >> A contributor is directed to the Fluid Licensing<https://wiki.
> fluidproject.org/display/fluid/Fluid+Licensing#FluidLicensing-
> ContributorLicenseAgreements> wiki page to sign either the CLA or the
> CCLA The contributor downloads the CLA or CCLA The contributor fills out
> the CLA or CCLA and scans or faxes it back to the IDRC We print off a copy
> of the CLA or CCLA and physically store it
> >>
> >> Pros
> >>
> >> * Official document signed with all of the contributors key details
> filled out
> >> * physical copy stored
> >>
> >> Cons
> >>
> >> * hard to co-ordinate with contributors, especially if they are in
> different timezones and/or they are contributing a single small change
> >> * hard to determine if a contributor has signed a CLA before
> >> * our current CLA doesn't record GitHub ID
> >>
> >> CLA Assistant
> >>
> >> CLA Assistant<https://cla-assistant.io> is an online service created
> by the GitHub team at SAP. It's an open source project and we would have
> the option to run our own instance if we choose.
> >>
> >> https://github.com/cla-assistant/cla-assistant
> >>
> >> Process to setup
> >>
> >> * One of our repo admins would save a CLA in a Gist on GitHub (I
> believe it can be public or private)
> >> * One of our repo admins would login to CLA Assistant with their GitHub
> account and link the repos to the CLA
> >>
> >> Process for a contributor
> >>
> >> You can test by submitting a PR to https://github.com/jobara/cla-
> assistant-testRepo
> >>
> >> * contributor submits a PR
> >> * CLA Assistant checks if the contributor has signed a CLA. It will
> mark the PR to indicate if it needs to be signed or not. (e.g.
> https://github.com/jobara/cla-assistant-testRepo/pull/1#
> issuecomment-378346476 <https://github.com/jobara/
> cla-assistant-testRepo/pull/1#issuecomment%E2%80%93378346476><
> https://github.com/jobara/cla-assistant-testRepo/pull/1#
> issuecomment%E2%80%93378346476> )
> >> * If a CLA hasn't been signed by the contributor, they are also
> e-mailed a notice that they are required to sign it.
> >> * The contributor clicks a link from the PR or the e-mail and they are
> shown the CLA and can click a button to sign it using their GitHub
> credentials.
> >>
> >> Pros
> >>
> >> * Easy to manage, it is all handled automatically
> >> * Can import existing contributors with a CSV file
> >> * Admins can log into the CLA Assistant interface to get a list of all
> of the contributors who have signed the CLA
> >> * Admins can export the list of contributors
> >>
> >> Cons
> >>
> >> * CLA Assistant requires a lot of access to our GitHub repos including
> being able to write to everything
> >>
> >> CLAHub
> >>
> >> CLAHub<https://www.clahub.com> is an open source project and online
> service now maintained<http://blog.clahub.com/post/141010202340/i-am-
> excited-to-share-that-the-berkman-center-for> by the Berkman Centre for
> Internet and Society at Harvard University<https://t.umblr.
> com/redirect?z=https%3A%2F%2Fcyber.law.harvard.edu%2F&t=
> NTllNjNlNTkyODQyMDZhZmRlZGYwNjQ4NWFhNzcxNGE3ODBhMzg1NSxRMDNR
> WkJWcw%3D%3D&b=t%3ArMn9v3DhLi-L8O2AL5K94Q&p=http%3A%2F%
> 2Fblog.clahub.com%2Fpost%2F141010202340%2Fi-am-excited-
> to-share-that-the-berkman-center-for&m=1>. We should also be able to
> setup our own instance if need be.
> >>
> >> https://github.com/clahub/clahub
> >>
> >> Process to setup
> >>
> >> * One of our repo admins would login to CLAHub with their GitHub
> credentials and register each repo
> >> * The admin would need to fill in the CLA text for each repo that is
> added.
> >> * The admin can also choose extra fields required to be signed (e-mail,
> name, mailing address, country, phone or Skype, Type "I AGREE", Type your
> initials, and Corporate Contributor Information)
> >>
> >> Process for a contributor
> >>
> >> You can test by submitting a PR to https://github.com/jobara/
> clahub-testRepo
> >>
> >> * contributor submits a PR
> >> * CLAHub checks if the contributor has signed a CLA. It will mark the
> PR to indicate if it needs to be signed or not. (e.g.
> https://github.com/jobara/clahub-testRepo/pull/1 )
> >> * The contributor clicks a link from the PR or contributing.md<http://
> contributing.md> file in the repo and they are shown the CLA and can
> click a button to sign it using their GitHub credentials. The contributor
> must fill in all the extra fields we requested.
> >>
> >> Pros
> >>
> >> * Easy to manage, it is all handled automatically
> >> * Admins can log into the CLA Assistant interface to get a list of all
> of the contributors who have signed the CLA
> >> * Admins can export the list of contributors
> >> * can provide the link to the CLA to signup from anywhere, e.g. a link
> in the contributing file
> >> * can require additional information from a contributor like their
> corporate affiliation
> >>
> >> Cons
> >>
> >> * CLAHub requires some access to GitHub repos
> >> * There doesn't seem to be a way to import contributor data
> >> * Requirement to sign CLA only shows up as a failed check on the PR. No
> comment is left, and no e-mail sent to the contributor.
> >> * CLAHub hasn't been updated for over a year
> _______________________________________________________
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
_______________________________________________________
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Reply via email to