You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Craig Russell <ap...@gmail.com> on 2021/07/07 23:53:04 UTC
New account creation tools
It looks like we have consensus that secretary needs to have some tooling to create new accounts.
Should we continue this discussion on the existing JIRAs? Create a new JIRA for whimsy? Or discuss here and then create JIRAs for the results?
One entry point is the secretary workbench where ICLAs are recorded. I believe that we need to add three fields to the ICLA form for the LDAP fields: family first, given name, and family name.
By default, if the requested id is filled, the given name should be the (family first)? cn[0] : cn[-1]
And the sn should be (family first)? cn[-1] : cn[0]
And do we really need the field for PMC Vote?
The second entry would be for secretary to handle new account requests from PMC members. The new-account-reqs.txt doesn't have quite enough information to create new accounts because it is missing sn and givenName. Should we define a new file format for the additional information or do something else entirely?
Craig
Craig L Russell
clr@apache.org
Re: New account creation tools
Posted by Craig Russell <ap...@gmail.com>.
Hi Sebb,
> On Jul 8, 2021, at 4:51 AM, sebb <se...@gmail.com> wrote:
>
> On Thu, 8 Jul 2021 at 00:53, Craig Russell <ap...@gmail.com> wrote:
>
>> And do we really need the field for PMC Vote?
>
> I think there needs to be some way to check that an email sent from a
> prospective committer has the backing of a (P)PMC.
> That is why I suggested separating the filing of the ICLA from
> requesting the account.
My interest is in minimizing the back-n-forth with the PMC, the prospective committer, secretary, and operations. IIRC, when I was secretary, I started doing the "new account request" as part of the ICLA filing because it reduced the round trips needed.
So for me, the minimum tripping needed is:
PMC votes a new committer and checks to see if the candidate is already a committer on another project or has already filed an ICLA.
- already a committer, PMC asks candidate and if accept, do the whimsy roster thing
- already filed an ICLA, PMC asks candidate to verify public name, email address and requested id, and if accept, do the whimsy new account thing (note that the whimsy new account thing might post an action for secretary or keep it like it is today)
- has not filed an ICLA, PMC asks candidate to verify not a committer and no icla yet filed, and please file an ICLA with email address, project, and requested id. Secretary does the rest, just like today.
>
> The potential committer sends the ICLA. This is checked for
> self-consistency (only) and filed, with a reply back to the sender and
> the (P)PMC if specified. The additional details required for LDAP are
> saved along with the email as key.
We do not need another round trip if everything is in order (VOTE from (P)PMC, project, requested id).
>
> If the request has the backing of the (P)PMC, they login to Whimsy to
> request that the account be created.
> They only need to provide the email.
My experience is that often the PMC does not know the email under which the ICLA was filed. I'll raise another mail thread on this topic.
> At which point the Secretary can
> create the LDAP account and add it to the committer group for the
> (P)PMC. It could be left to the (P)PMC to add them as members once the
> NOTICE has been served.
NOTICE should be given and 72 hours passed before inviting the candidate.
>
> If it is desired that the Secretary take on this role as well, then
> the PMC will need to confirm that the proper NOTICE has been served.
> However I think that PMCs need to take full responsibility for
> updating their committee. Why should the Secretary do it when a new
> account is being created and not subsequently?
Many times the ICLA is filed missing important information which the candidate should provide at the time they accept the invitation.
>
>> The second entry would be for secretary to handle new account requests from PMC members. The new-account-reqs.txt doesn't have quite enough information to create new accounts because it is missing sn and givenName. Should we define a new file format for the additional information or do something else entirely?
Let's not define a new file format. If the original ICLA is missing information (project, requested id, updated email address), the candidate should provide it in reply to the PMC invitation. Secretary can use their judgement to provide the original sn and givenName, and if the new committer doesn't like it, they can change it themself.
Best,
Craig
>
> See above.
>
>> Craig
>>
>> Craig L Russell
>> clr@apache.org
>>
Craig L Russell
clr@apache.org
Re: Secretary workbench ICLA screen family first, sn, and givenName
Posted by Craig Russell <ap...@gmail.com>.
I looked at other parts of the workbench and now think I can come up with at least a partial patch.
I'll create a new branch to work in for you all to review.
Craig
> On Jul 13, 2021, at 8:12 AM, sebb <se...@gmail.com> wrote:
>
> On Sat, 10 Jul 2021 at 22:33, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
>>
>> Hi Sebb,
>>
>>> On Jul 8, 2021, at 4:51 AM, sebb <se...@gmail.com> wrote:
>>>
>>>> One entry point is the secretary workbench where ICLAs are recorded. I believe that we need to add three fields to the ICLA form for the LDAP fields: family first, given name, and family name.
>>>
>>> I agree about given name and family name.
>>> The field 'family first' is unnecessary and confusing.
>>
>> I'm referring here specifically to the secretary workbench ICLA screen, not the ICLA.pdf form. The "[x] Family First" is on the ICLA form, and should be shown on the ICLA screen as a yes/no box that can be edited if secretary decides that it is incorrect (or an old form that doesn't include it).
>>>
>>>> By default, if the requested id is filled, the given name should be the (family first)? cn[0] : cn[-1]
>>>> And the sn should be (family first)? cn[-1] : cn[0]
>>>
>>> We should not try to parse the Public Name; instead family name should
>>> be required on the ICLA.
>>
>> The LDAP fields are an artifact of how we choose to handle things in infra and have nothing to do with the legal document. We might choose in future to put stuff into a database instead of LDAP and get rid of the cn, sn, givenName artifacts entirely.
>>
>> But secretary still needs to fill the LDAP fields from information on the ICLA and as it is today, there just is not enough information to do it. But with the Family First flag, we have enough information to derive the sn and givenName from the Public name.
>
> The Family first flag gives enough information to make a guess at the
> sn and givenName.
> It does not guarantee these will be derived correctly, and there is no
> guarantee that the person has understood whether they need to check
> the box or not.
> However the latest proposed wording is at least easier to understand.
>
>> So the ICLA screen needs to add the Family First flag, the derived (editable by Secretary) sn and givenName fields. These will be needed only for account creation so they should be listed below the "requested Apache id" part of the screen.
>
> We don't *need* the flag.
> We could ask for family name and givenName instead.
> Or we could guess them.
>
> Or we could set the family name to a fixed value and omit the givenName.
> That would satisfy the LDAP schema and AFAICT would not affect
> anything that LDAP is used for.
>
> If it were important to have accurate sn and givenName I would have
> expected to see complaints that the incorrect values are causing
> problems.
>
>> Regards,
>> Craig
>>
>> Craig L Russell
>> clr@apache.org <ma...@apache.org>
Craig L Russell
clr@apache.org
Re: Secretary workbench ICLA screen family first, sn, and givenName
Posted by Craig Russell <ap...@gmail.com>.
> On Jul 13, 2021, at 8:12 AM, sebb <se...@gmail.com> wrote:
>
> On Sat, 10 Jul 2021 at 22:33, Craig Russell <ap...@gmail.com> wrote:
>>
>> Hi Sebb,
>>
>>> On Jul 8, 2021, at 4:51 AM, sebb <se...@gmail.com> wrote:
>>>
>>>> One entry point is the secretary workbench where ICLAs are recorded. I believe that we need to add three fields to the ICLA form for the LDAP fields: family first, given name, and family name.
>>>
>>> I agree about given name and family name.
>>> The field 'family first' is unnecessary and confusing.
>>
>> I'm referring here specifically to the secretary workbench ICLA screen, not the ICLA.pdf form. The "[x] Family First" is on the ICLA form, and should be shown on the ICLA screen as a yes/no box that can be edited if secretary decides that it is incorrect (or an old form that doesn't include it).
>>>
>>>> By default, if the requested id is filled, the given name should be the (family first)? cn[0] : cn[-1]
>>>> And the sn should be (family first)? cn[-1] : cn[0]
>>>
>>> We should not try to parse the Public Name; instead family name should
>>> be required on the ICLA.
>>
>> The LDAP fields are an artifact of how we choose to handle things in infra and have nothing to do with the legal document. We might choose in future to put stuff into a database instead of LDAP and get rid of the cn, sn, givenName artifacts entirely.
>>
>> But secretary still needs to fill the LDAP fields from information on the ICLA and as it is today, there just is not enough information to do it. But with the Family First flag, we have enough information to derive the sn and givenName from the Public name.
>
> The Family first flag gives enough information to make a guess at the
> sn and givenName.
> It does not guarantee these will be derived correctly, and there is no
> guarantee that the person has understood whether they need to check
> the box or not.
> However the latest proposed wording is at least easier to understand.
What I failed to say earlier is that if the family first box is checked, the file name should be reversed to <given>-<family>.pdf to be consistent with the existing file names. So I do believe that we should add the check box to the ICLA screen. And add the givenName and sn to the screen as well.
I looked at workbench/views/forms/icla.js.rb and found a place for the family first flag, probably just after:
_tr do
_th 'Public Name'
_td do
_input name: 'pubname', value: @pubname, required: true,
disabled: (@filed or @pdfbusy), onFocus: lambda {@pubname ||= @realname}
end
end
We would need to add a _th 'Family First' with an _input field, value @familyfirst, required true.
And the givenName and sn fields should be added, perhaps after the User ID field because it's only needed for new account creation?
What I could not find is how to use _input to define a check box. I found a reference volume for the Vue stuff but I'm missing our extensions.
We also need to adapt the PDF parser (I think the parsing is done in the back end).
I'm pretty sure I do not have the technical skills to complete this project. Would it be ok to start a new branch with a sketch of what we need to update the icla screen for the new ICLA?
Or is there a better way to proceed?
>
>> So the ICLA screen needs to add the Family First flag, the derived (editable by Secretary) sn and givenName fields. These will be needed only for account creation so they should be listed below the "requested Apache id" part of the screen.
>
> We don't *need* the flag.
> We could ask for family name and givenName instead.
> Or we could guess them.
Yes, and whatever the computer guesses should be overridden by the Secretary with a bit more deep learning under their belt. I just hate to make the Secretary type stuff that some shallow learning computer can offer as a good guess.
>
> Or we could set the family name to a fixed value and omit the givenName.
> That would satisfy the LDAP schema and AFAICT would not affect
> anything that LDAP is used for.
>
> If it were important to have accurate sn and givenName I would have
> expected to see complaints that the incorrect values are causing
> problems.
It would be an interesting bit of history to figure out exactly who decided that we should use the LDAP "person" protocol that *requires* both cn and sn. Our usage of Public Name does not fit that description of "person" and we should have left well enough with only having a cn instead of going full "person" LDAP.
Craig
>
>> Regards,
>> Craig
>>
>> Craig L Russell
>> clr@apache.org
>>
Craig L Russell
clr@apache.org
Re: Secretary workbench ICLA screen family first, sn, and givenName
Posted by sebb <se...@gmail.com>.
On Sat, 10 Jul 2021 at 22:33, Craig Russell <ap...@gmail.com> wrote:
>
> Hi Sebb,
>
> > On Jul 8, 2021, at 4:51 AM, sebb <se...@gmail.com> wrote:
> >
> >> One entry point is the secretary workbench where ICLAs are recorded. I believe that we need to add three fields to the ICLA form for the LDAP fields: family first, given name, and family name.
> >
> > I agree about given name and family name.
> > The field 'family first' is unnecessary and confusing.
>
> I'm referring here specifically to the secretary workbench ICLA screen, not the ICLA.pdf form. The "[x] Family First" is on the ICLA form, and should be shown on the ICLA screen as a yes/no box that can be edited if secretary decides that it is incorrect (or an old form that doesn't include it).
> >
> >> By default, if the requested id is filled, the given name should be the (family first)? cn[0] : cn[-1]
> >> And the sn should be (family first)? cn[-1] : cn[0]
> >
> > We should not try to parse the Public Name; instead family name should
> > be required on the ICLA.
>
> The LDAP fields are an artifact of how we choose to handle things in infra and have nothing to do with the legal document. We might choose in future to put stuff into a database instead of LDAP and get rid of the cn, sn, givenName artifacts entirely.
>
> But secretary still needs to fill the LDAP fields from information on the ICLA and as it is today, there just is not enough information to do it. But with the Family First flag, we have enough information to derive the sn and givenName from the Public name.
The Family first flag gives enough information to make a guess at the
sn and givenName.
It does not guarantee these will be derived correctly, and there is no
guarantee that the person has understood whether they need to check
the box or not.
However the latest proposed wording is at least easier to understand.
> So the ICLA screen needs to add the Family First flag, the derived (editable by Secretary) sn and givenName fields. These will be needed only for account creation so they should be listed below the "requested Apache id" part of the screen.
We don't *need* the flag.
We could ask for family name and givenName instead.
Or we could guess them.
Or we could set the family name to a fixed value and omit the givenName.
That would satisfy the LDAP schema and AFAICT would not affect
anything that LDAP is used for.
If it were important to have accurate sn and givenName I would have
expected to see complaints that the incorrect values are causing
problems.
> Regards,
> Craig
>
> Craig L Russell
> clr@apache.org
>
Secretary workbench ICLA screen family first, sn, and givenName
Posted by Craig Russell <ap...@gmail.com>.
Hi Sebb,
> On Jul 8, 2021, at 4:51 AM, sebb <se...@gmail.com> wrote:
>
>> One entry point is the secretary workbench where ICLAs are recorded. I believe that we need to add three fields to the ICLA form for the LDAP fields: family first, given name, and family name.
>
> I agree about given name and family name.
> The field 'family first' is unnecessary and confusing.
I'm referring here specifically to the secretary workbench ICLA screen, not the ICLA.pdf form. The "[x] Family First" is on the ICLA form, and should be shown on the ICLA screen as a yes/no box that can be edited if secretary decides that it is incorrect (or an old form that doesn't include it).
>
>> By default, if the requested id is filled, the given name should be the (family first)? cn[0] : cn[-1]
>> And the sn should be (family first)? cn[-1] : cn[0]
>
> We should not try to parse the Public Name; instead family name should
> be required on the ICLA.
The LDAP fields are an artifact of how we choose to handle things in infra and have nothing to do with the legal document. We might choose in future to put stuff into a database instead of LDAP and get rid of the cn, sn, givenName artifacts entirely.
But secretary still needs to fill the LDAP fields from information on the ICLA and as it is today, there just is not enough information to do it. But with the Family First flag, we have enough information to derive the sn and givenName from the Public name.
So the ICLA screen needs to add the Family First flag, the derived (editable by Secretary) sn and givenName fields. These will be needed only for account creation so they should be listed below the "requested Apache id" part of the screen.
Regards,
Craig
Craig L Russell
clr@apache.org
Re: New account creation tools
Posted by sebb <se...@gmail.com>.
On Thu, 8 Jul 2021 at 00:53, Craig Russell <ap...@gmail.com> wrote:
>
> It looks like we have consensus that secretary needs to have some tooling to create new accounts.
>
> Should we continue this discussion on the existing JIRAs? Create a new JIRA for whimsy? Or discuss here and then create JIRAs for the results?
>
> One entry point is the secretary workbench where ICLAs are recorded. I believe that we need to add three fields to the ICLA form for the LDAP fields: family first, given name, and family name.
I agree about given name and family name.
The field 'family first' is unnecessary and confusing.
> By default, if the requested id is filled, the given name should be the (family first)? cn[0] : cn[-1]
> And the sn should be (family first)? cn[-1] : cn[0]
We should not try to parse the Public Name; instead family name should
be required on the ICLA.
> And do we really need the field for PMC Vote?
I think there needs to be some way to check that an email sent from a
prospective committer has the backing of a (P)PMC.
That is why I suggested separating the filing of the ICLA from
requesting the account.
The potential committer sends the ICLA. This is checked for
self-consistency (only) and filed, with a reply back to the sender and
the (P)PMC if specified. The additional details required for LDAP are
saved along with the email as key.
If the request has the backing of the (P)PMC, they login to Whimsy to
request that the account be created.
They only need to provide the email. At which point the Secretary can
create the LDAP account and add it to the committer group for the
(P)PMC. It could be left to the (P)PMC to add them as members once the
NOTICE has been served.
If it is desired that the Secretary take on this role as well, then
the PMC will need to confirm that the proper NOTICE has been served.
However I think that PMCs need to take full responsibility for
updating their committee. Why should the Secretary do it when a new
account is being created and not subsequently?
> The second entry would be for secretary to handle new account requests from PMC members. The new-account-reqs.txt doesn't have quite enough information to create new accounts because it is missing sn and givenName. Should we define a new file format for the additional information or do something else entirely?
See above.
> Craig
>
> Craig L Russell
> clr@apache.org
>