-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store more information about the CLA signer #64
Comments
Thank you for your proposal, Stefan. |
I am also considering using cla-assistant for an open source project at work, and storing emails, names, or any other information available other than just github username would be a wonderful feature and would make it much easier to adopt cla-assistant in many organizations. |
@KharitonOff What if the CLA gist could contain some metadata about additional required fields that each organization wants to collect -- e.g. email address or full/legal name. It wouldn't have to be automatically enabled for all CLA-Assistant users (satisfies the streamlining criteria), but places that want this extra information could collect it. |
Thank you for your proposal, we are thinking in the same direction: provide an opportunity to add required fields... We'll take your Idea to use metadata in gist in consideration. Do you have any example or ideas how it could look like? |
@KharitonOff something like:
Which would cause 3 text fields to be created, 2 of them required (the ones with My only concern would be what text that might trigger this formatting may already exist in CLAs out there. If I were someone using CLA Assistant, I wouldn't want my CLA form changing out from under me. Is there a way to grandfather in existing CLAs, and have this feature only apply to newly created ones? |
@dcrosta right now, I think we would rather provide a fixed set of predefined (optional) fields instead of mixing that with the CLA text itself (which might cause some problems). The assumption right now is that these optional fields would be more or less similar for different projects. Feedback appreciated. |
Thanks for looking into this issue. Fields I would like to suggest:
Offering predefined fields is probably the easiest solution to implement. However I would like to suggest to be able to add an own description to each field or at least to the whole form. For example the amount of information needed regarding the employer might differ from project to project. If you are looking for a generic solution covering all use cases you could take a look at JSONSchema. The user could then add an own schema to each CLA (for example via Gist) from which each form is generated. Example Schema:
|
From our attorney, these are the fields we'd want in addition to the general CLA agreement:
Re #3, our CLA says "If Your contribution is on behalf of an entity (such as your employer), or if there is an entity that has rights to your contribution ...", so we want to know who those entities are. Re #4, we believe that having to take a separate action -- checking the checkbox -- is a stronger sign of commitment than just clicking the big button (a habit that many of us are in, just to get the message to go away). Numbers 1, 2, and 4 should be required (or we should have the option to make them required) As I indicated before, ideally, we'd like to be able to customize the text along with these extra fields, as well as which fields appear. I still think that having some kind of metadata with the CLA, or possibly in a separate gist, will be the most general and useful way to support this feature; but if instead it ended up as some configuration done through the CLA Assistant webapp for each repo, that would be fine for us too. |
Just adding a bit of feedback in support of this issue: We are hoping to use the CLA assistant with this project: Once of the concerns here is that the click-thru functionality as presented here does not or may not quite pass the legal muster, and so if we could design the process in such a way where additional data is collected from the contributor at least in the form of name and email address that would be great. |
I'm also looking at using CLA Assistant with agreements from Harmony Agreements. When you generate these agreements, they specifically want name and address. I am nervous about removing these fields because I am not fortunate enough to have easy access to legal advice. It would be really helpful if this were given priority. |
We are willing to test as soon as it's out :) |
@sdirix, @reem, @dcrosta, @mmoayyed, @camlorn, @lipis, @matz3, @jdanyow, @ejsmith, @niemyjski
You can try the current state on our staging instance: https://preview.cla-assistant.io/ What's in:
Thanks a lot for your valuable feedback and for your support! |
@KharitonOff Awesome stuff! What about ...
"category": {
"title": "How do you sign?",
"type": "radio",
"items": [
{
"name": "myself",
"title": "I am signing on behalf of myself."
},
{
"name": "employer",
"title": "I am signing on behalf of my employer."
}
]
}
... |
I created a dummy projects for testing it this and it looks my "testers" are getting |
It looks like you have to be logged in to https://preview.cla-assistant.io before signing (if it's just part of the preview then it's totally fine). |
@lipis : 👍 thank you very much for testing and issue reporting! I've fixed the logging issue. Now the signer should see the CLA without logging into the tool. Radio-buttons should work now too. I changed your proposal to following schema:
The 'description' attribute is currently used for tool-tip... I'll discuss with our designer your suggestion. |
Good stuff! The schema is even simpler so that's perfect.. As for the description don't forget the mobile users.. one design to rule them all.. simple text as suggested is more straightforward as people have to read the whole thing anyway since it's a CLA.. Plus it will be clearer to make as less mistakes as possible. |
This looks great -- many thanks! Any idea when it will be released to the production CLA-Assistant? |
Thank you very very much for implementing this feature! I really like that you went with the flexible route of allowing users to create form descriptions. I tested the preview and it works as expected! Great! As @lipis already mentioned, I would also strongly prefer that the 'description' is rendered as text above or below the input. Currently when the metadata is invalid, the user only sees an error message which looks like this:
I would like to suggest to catch errors like this (see also my next point at how to do it) and then still display the CLA but with an additional info that the form could not be rendered and the user should contact the repository owner to sort the problem out. My greatest remark is about your use of JSONSchema. You have mainly two options to support JSONSchema:
What you currently do is to define an own schema format which looks similar to JSONSchema but is actually incompatible. You can check this with the validator I linked below. If you want to go the route of the first option, then you let the user define their own schema, read in the schema and generate from it the form and database entries. However I guess the second option is actually closer to the workflow you currently expect. Your schema and an example schema instance (the 'metadata' file) could then look like this:
Explanation: You expect an array of objects. These objects must adhere to the the type you defined in This means the data in the
One advantage of this approach is, that you can for example validate the 'metadata' gist once the user links it on the dashboard. There exist many validators for JSONSchema. Here is an example of an online validator: jsonschemavalidator. Copy my example schema to the left and the example metadata to the right and you will see that it successfully validates. When you enter invalid data you immediately get a nice error message. Since you did not yet introduce the feature into the productive build I would strongly suggest to define a clean json schema (you can use mine if you want) before you get any legacy problems. You can of course also use your current (informal) definition, but since it closely resembles what the JSONSchema specification itself looks like it has a a lot of overhead. Thank you again for your great work! Once this feature is integrated there should be no more obstacles to finally use the cla-assistant within our projects! |
Ok, I see! Thank you for pointing out my misunderstanding! 😏 And yes, I prefer creating our own Schema. I've described it now, based on your suggestion:
The metadata json could look like this one:
@lipis , @sdirix : regarding description: we have decided to put the description in the input field (in sense of consistency) like we have it in the "link screen" : |
Just my 50cents.. the Instructions should be always visible for clarity. |
@lipis ok, thank you for your input! In your proposal the space between the fields with and without description would be unequal. We've placed the description out of the input field, behind the label. |
Looks pretty good!! Thank you.. |
@KharitonOff this is all looking very very good :) Any idea when it will be released to production? |
@dcrosta we are going to release it next week 🙂 |
We decided to release v1.4 today to production |
The CLA assistant really helps to deal with CLA signments for GitHub projects in an easy and intuitive way.
Currently the information collected about the CLA signer is limited to the GitHub username. This could lead to traceability problems when a contributer deletes his GitHub account or does not use GitHub anymore. Also some organisations request more information about contributors in general.
Therefore I wanted to ask if you are interested in extending the signment process by collecting more information about the user via a form (name, address, email, phone etc.) or via the GitHub-API querying the signer's GitHub profile. This data could then easily be stored in some additional fields of the mongo-db.
The text was updated successfully, but these errors were encountered: