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 2020/07/06 17:13:52 UTC
Re: roster-emeritus PR #94 is ready for final review and some
improvements suggested
Just one final observation.
The emeritus work flow once this PR is merged:
Member decides to go emeritus, navigates to their profile, and clicks (request emeritus). This generates an emeritus request document and sends mail to secretary.
Secretary receives the mail, reviews the request, and files it in emeritus-requests-received, and sends mail to the member.
Ten days (or so) elapse.
Secretary remembers that there is a pending emeritus request, navigates to emeritus-requests-received, reviews the documents there, calculates the effective date, and then navigates to the member's profile, double clicks Member status, and clicks (emeritus).
This can be improved:
1. The Member status box to (request emeritus) could directly put the request into the proper place in emeritus-requests-received and send mail to the member acknowledging the request. Secretary does not need to be involved at this phase. Member could still rescind the emeritus request without getting secretary involved.
2. The secretary workbench could scan the emeritus-requests-received along with the incoming mail and post a separate list of things to do if there are any pending emeritus requests. If secretary then examines the emeritus request document, actions could include (emeritus) which would then do what Member status does today.
WDYT?
Craig
> On Jul 4, 2020, at 2:17 PM, Craig Russell <ap...@gmail.com> wrote:
>
> I believe this PR is ready for final review. Please let me know if you have any concerns.
>
> https://github.com/apache/whimsy/pull/94
>
> Thanks,
>
> Craig
>
> Craig L Russell
> clr@apache.org
>
Craig L Russell
clr@apache.org
Re: Some improvements suggested for emeritus work flow
Posted by sebb <se...@gmail.com>.
On Tue, 7 Jul 2020 at 23:19, Craig Russell <ap...@gmail.com> wrote:
>
> Hi Sebb,
>
> Thanks for the comments.
>
> On Jul 7, 2020, at 12:56 PM, sebb <se...@gmail.com> wrote:
>
> On Tue, 7 Jul 2020 at 18:12, Craig Russell <ap...@gmail.com> wrote:
>
>
> I'd like some feedback on this proposal.
>
> My objective in this project was and still is to allow members to easily if not trivially change their status to emeritus. A secondary objective is to make Secretary's work flow as easy as practical.
>
> So, I'd like feedback specifically on having the (request emeritus status) button on the member's __self__ page to automatically file the request document in emeritus-requests-received and send notice to secretary. Secretary would not need to do anything until the 10 day rescission period has ended, at which point Secretary would use a tool to make the member emeritus. Tooling is not the important feedback request here.
>
> Anyone have an opinion?
>
>
> Auto-filing seems OK to me.
>
> If the member files a second request before the first has been
> processed,
>
>
> The roster __self__ tool will not allow filing a second request. The (request emeritus status) button is only available if the user is active without a pending request. [1]
>
> So the second request can only occur if the member files a request manually. By sending mail to secretary. Which has never happened during the last 15 years that I've been paying attention.
OK, so not an issue.
> I think there are 2 options:
> - reject the second attempt.
> - replace the file with the new one. This may cause the 10 day period to reset.
>
> I don't see any value in keeping multiple copies of the request online at once.
> SVN will give access to earlier versions if really necessary.
>
>
> Also, we can consider removing the emeritus-requests-rescinded files after some time to avoid duplicates if the member subsequently files another request that is also rescinded.
Or just replace the file with the new version.
Much the same effect, but easier to follow the history.
>
>
> [1] if owner
> if committer.member.status.include? 'Active'
> if committer.forms['emeritus_request']
> emeritus_file_url = committer.forms['emeritus_request']
> _button.btn.btn_primary 'rescind emeritus request',
> data_emeritus_file_url:emeritus_file_url,
> name: 'action', value: 'rescind_emeritus'
> else
> _button.btn.btn_primary 'request emeritus status',
> data_emeritus_person_name:@@person.public_name,
> name: 'action', value: 'request_emeritus'
> end
> elsif committer.member.status.include? 'Emeritus'
> _button.btn.btn_primary 'request reinstatement',
> name: 'action', value: 'request_reinstatement'
> end
> end
>
> Thanks,
> Craig
>
> On Jul 6, 2020, at 10:13 AM, Craig Russell <ap...@gmail.com> wrote:
>
> Just one final observation.
>
> The emeritus work flow once this PR is merged:
>
> Member decides to go emeritus, navigates to their profile, and clicks (request emeritus). This generates an emeritus request document and sends mail to secretary.
>
> Secretary receives the mail, reviews the request, and files it in emeritus-requests-received, and sends mail to the member.
>
> Ten days (or so) elapse.
>
> Secretary remembers that there is a pending emeritus request, navigates to emeritus-requests-received, reviews the documents there, calculates the effective date, and then navigates to the member's profile, double clicks Member status, and clicks (emeritus).
>
> This can be improved:
>
> 1. The Member status box to (request emeritus) could directly put the request into the proper place in emeritus-requests-received and send mail to the member acknowledging the request. Secretary does not need to be involved at this phase. Member could still rescind the emeritus request without getting secretary involved.
>
> 2. The secretary workbench could scan the emeritus-requests-received along with the incoming mail and post a separate list of things to do if there are any pending emeritus requests. If secretary then examines the emeritus request document, actions could include (emeritus) which would then do what Member status does today.
>
> WDYT?
>
> Craig
>
> On Jul 4, 2020, at 2:17 PM, Craig Russell <ap...@gmail.com> wrote:
>
> I believe this PR is ready for final review. Please let me know if you have any concerns.
>
> https://github.com/apache/whimsy/pull/94
>
> Thanks,
>
> Craig
>
> Craig L Russell
> clr@apache.org
>
>
> Craig L Russell
> clr@apache.org
>
>
> Craig L Russell
> clr@apache.org
>
>
> Craig L Russell
> clr@apache.org
>
Re: Some improvements suggested for emeritus work flow
Posted by Craig Russell <ap...@gmail.com>.
Hi Sebb,
Thanks for the comments.
> On Jul 7, 2020, at 12:56 PM, sebb <se...@gmail.com> wrote:
>
> On Tue, 7 Jul 2020 at 18:12, Craig Russell <apache.clr@gmail.com <ma...@gmail.com>> wrote:
>>
>> I'd like some feedback on this proposal.
>>
>> My objective in this project was and still is to allow members to easily if not trivially change their status to emeritus. A secondary objective is to make Secretary's work flow as easy as practical.
>>
>> So, I'd like feedback specifically on having the (request emeritus status) button on the member's __self__ page to automatically file the request document in emeritus-requests-received and send notice to secretary. Secretary would not need to do anything until the 10 day rescission period has ended, at which point Secretary would use a tool to make the member emeritus. Tooling is not the important feedback request here.
>>
>> Anyone have an opinion?
>
> Auto-filing seems OK to me.
>
> If the member files a second request before the first has been
> processed,
The roster __self__ tool will not allow filing a second request. The (request emeritus status) button is only available if the user is active without a pending request. [1]
So the second request can only occur if the member files a request manually. By sending mail to secretary. Which has never happened during the last 15 years that I've been paying attention.
> I think there are 2 options:
> - reject the second attempt.
> - replace the file with the new one. This may cause the 10 day period to reset.
>
> I don't see any value in keeping multiple copies of the request online at once.
> SVN will give access to earlier versions if really necessary.
Also, we can consider removing the emeritus-requests-rescinded files after some time to avoid duplicates if the member subsequently files another request that is also rescinded.
>
>
[1] if owner
if committer.member.status.include? 'Active'
if committer.forms['emeritus_request']
emeritus_file_url = committer.forms['emeritus_request']
_button.btn.btn_primary 'rescind emeritus request',
data_emeritus_file_url:emeritus_file_url,
name: 'action', value: 'rescind_emeritus'
else
_button.btn.btn_primary 'request emeritus status',
data_emeritus_person_name:@@person.public_name,
name: 'action', value: 'request_emeritus'
end
elsif committer.member.status.include? 'Emeritus'
_button.btn.btn_primary 'request reinstatement',
name: 'action', value: 'request_reinstatement'
end
end
>> Thanks,
>> Craig
>>
>>> On Jul 6, 2020, at 10:13 AM, Craig Russell <ap...@gmail.com> wrote:
>>>
>>> Just one final observation.
>>>
>>> The emeritus work flow once this PR is merged:
>>>
>>> Member decides to go emeritus, navigates to their profile, and clicks (request emeritus). This generates an emeritus request document and sends mail to secretary.
>>>
>>> Secretary receives the mail, reviews the request, and files it in emeritus-requests-received, and sends mail to the member.
>>>
>>> Ten days (or so) elapse.
>>>
>>> Secretary remembers that there is a pending emeritus request, navigates to emeritus-requests-received, reviews the documents there, calculates the effective date, and then navigates to the member's profile, double clicks Member status, and clicks (emeritus).
>>>
>>> This can be improved:
>>>
>>> 1. The Member status box to (request emeritus) could directly put the request into the proper place in emeritus-requests-received and send mail to the member acknowledging the request. Secretary does not need to be involved at this phase. Member could still rescind the emeritus request without getting secretary involved.
>>>
>>> 2. The secretary workbench could scan the emeritus-requests-received along with the incoming mail and post a separate list of things to do if there are any pending emeritus requests. If secretary then examines the emeritus request document, actions could include (emeritus) which would then do what Member status does today.
>>>
>>> WDYT?
>>>
>>> Craig
>>>
>>>> On Jul 4, 2020, at 2:17 PM, Craig Russell <ap...@gmail.com> wrote:
>>>>
>>>> I believe this PR is ready for final review. Please let me know if you have any concerns.
>>>>
>>>> https://github.com/apache/whimsy/pull/94
>>>>
>>>> Thanks,
>>>>
>>>> Craig
>>>>
>>>> Craig L Russell
>>>> clr@apache.org
>>>>
>>>
>>> Craig L Russell
>>> clr@apache.org
>>>
>>
>> Craig L Russell
>> clr@apache.org
Craig L Russell
clr@apache.org
Re: Some improvements suggested for emeritus work flow
Posted by sebb <se...@gmail.com>.
On Tue, 7 Jul 2020 at 18:12, Craig Russell <ap...@gmail.com> wrote:
>
> I'd like some feedback on this proposal.
>
> My objective in this project was and still is to allow members to easily if not trivially change their status to emeritus. A secondary objective is to make Secretary's work flow as easy as practical.
>
> So, I'd like feedback specifically on having the (request emeritus status) button on the member's __self__ page to automatically file the request document in emeritus-requests-received and send notice to secretary. Secretary would not need to do anything until the 10 day rescission period has ended, at which point Secretary would use a tool to make the member emeritus. Tooling is not the important feedback request here.
>
> Anyone have an opinion?
Auto-filing seems OK to me.
If the member files a second request before the first has been
processed, I think there are 2 options:
- reject the second attempt.
- replace the file with the new one. This may cause the 10 day period to reset.
I don't see any value in keeping multiple copies of the request online at once.
SVN will give access to earlier versions if really necessary.
> Thanks,
> Craig
>
> > On Jul 6, 2020, at 10:13 AM, Craig Russell <ap...@gmail.com> wrote:
> >
> > Just one final observation.
> >
> > The emeritus work flow once this PR is merged:
> >
> > Member decides to go emeritus, navigates to their profile, and clicks (request emeritus). This generates an emeritus request document and sends mail to secretary.
> >
> > Secretary receives the mail, reviews the request, and files it in emeritus-requests-received, and sends mail to the member.
> >
> > Ten days (or so) elapse.
> >
> > Secretary remembers that there is a pending emeritus request, navigates to emeritus-requests-received, reviews the documents there, calculates the effective date, and then navigates to the member's profile, double clicks Member status, and clicks (emeritus).
> >
> > This can be improved:
> >
> > 1. The Member status box to (request emeritus) could directly put the request into the proper place in emeritus-requests-received and send mail to the member acknowledging the request. Secretary does not need to be involved at this phase. Member could still rescind the emeritus request without getting secretary involved.
> >
> > 2. The secretary workbench could scan the emeritus-requests-received along with the incoming mail and post a separate list of things to do if there are any pending emeritus requests. If secretary then examines the emeritus request document, actions could include (emeritus) which would then do what Member status does today.
> >
> > WDYT?
> >
> > Craig
> >
> >> On Jul 4, 2020, at 2:17 PM, Craig Russell <ap...@gmail.com> wrote:
> >>
> >> I believe this PR is ready for final review. Please let me know if you have any concerns.
> >>
> >> https://github.com/apache/whimsy/pull/94
> >>
> >> Thanks,
> >>
> >> Craig
> >>
> >> Craig L Russell
> >> clr@apache.org
> >>
> >
> > Craig L Russell
> > clr@apache.org
> >
>
> Craig L Russell
> clr@apache.org
>
Some improvements suggested for emeritus work flow
Posted by Craig Russell <ap...@gmail.com>.
I'd like some feedback on this proposal.
My objective in this project was and still is to allow members to easily if not trivially change their status to emeritus. A secondary objective is to make Secretary's work flow as easy as practical.
So, I'd like feedback specifically on having the (request emeritus status) button on the member's __self__ page to automatically file the request document in emeritus-requests-received and send notice to secretary. Secretary would not need to do anything until the 10 day rescission period has ended, at which point Secretary would use a tool to make the member emeritus. Tooling is not the important feedback request here.
Anyone have an opinion?
Thanks,
Craig
> On Jul 6, 2020, at 10:13 AM, Craig Russell <ap...@gmail.com> wrote:
>
> Just one final observation.
>
> The emeritus work flow once this PR is merged:
>
> Member decides to go emeritus, navigates to their profile, and clicks (request emeritus). This generates an emeritus request document and sends mail to secretary.
>
> Secretary receives the mail, reviews the request, and files it in emeritus-requests-received, and sends mail to the member.
>
> Ten days (or so) elapse.
>
> Secretary remembers that there is a pending emeritus request, navigates to emeritus-requests-received, reviews the documents there, calculates the effective date, and then navigates to the member's profile, double clicks Member status, and clicks (emeritus).
>
> This can be improved:
>
> 1. The Member status box to (request emeritus) could directly put the request into the proper place in emeritus-requests-received and send mail to the member acknowledging the request. Secretary does not need to be involved at this phase. Member could still rescind the emeritus request without getting secretary involved.
>
> 2. The secretary workbench could scan the emeritus-requests-received along with the incoming mail and post a separate list of things to do if there are any pending emeritus requests. If secretary then examines the emeritus request document, actions could include (emeritus) which would then do what Member status does today.
>
> WDYT?
>
> Craig
>
>> On Jul 4, 2020, at 2:17 PM, Craig Russell <ap...@gmail.com> wrote:
>>
>> I believe this PR is ready for final review. Please let me know if you have any concerns.
>>
>> https://github.com/apache/whimsy/pull/94
>>
>> Thanks,
>>
>> Craig
>>
>> Craig L Russell
>> clr@apache.org
>>
>
> Craig L Russell
> clr@apache.org
>
Craig L Russell
clr@apache.org
Re: roster-emeritus PR #94 is ready for final review and some
improvements suggested
Posted by Craig Russell <ap...@gmail.com>.
> On Jul 6, 2020, at 1:10 PM, sebb <se...@gmail.com> wrote:
>
> On Mon, 6 Jul 2020 at 18:14, Craig Russell <ap...@gmail.com> wrote:
>>
>> Just one final observation.
>>
>> The emeritus work flow once this PR is merged:
>>
>> Member decides to go emeritus, navigates to their profile, and clicks (request emeritus). This generates an emeritus request document and sends mail to secretary.
>>
>> Secretary receives the mail, reviews the request, and files it in emeritus-requests-received, and sends mail to the member.
>>
>> Ten days (or so) elapse.
>>
>> Secretary remembers that there is a pending emeritus request, navigates to emeritus-requests-received, reviews the documents there, calculates the effective date, and then navigates to the member's profile, double clicks Member status, and clicks (emeritus).
>>
>> This can be improved:
>>
>> 1. The Member status box to (request emeritus) could directly put the request into the proper place in emeritus-requests-received and send mail to the member acknowledging the request. Secretary does not need to be involved at this phase. Member could still rescind the emeritus request without getting secretary involved.
>>
>> 2. The secretary workbench could scan the emeritus-requests-received along with the incoming mail and post a separate list of things to do if there are any pending emeritus requests. If secretary then examines the emeritus request document, actions could include (emeritus) which would then do what Member status does today.
>>
>> WDYT?
>
> Member may no longer have access to their password, so it must be
> possible for them to email Secretary instead of using Whimsy.
In order for the member to file an emeritus request today they need to download a form from svn foundation/emeritus-request.pdf or .txt, sign, scan, and email.
IIUC they cannot access svn foundation without a password. In that case, they would need to send email to secretary and hope that secretary will ack the request.
Also IIUC, this has been done at least a dozen times before.
So having access to the pdf form requires the same credentials as access to the whimsy __self__ page.
Craig
>
>> Craig
>>
>>> On Jul 4, 2020, at 2:17 PM, Craig Russell <ap...@gmail.com> wrote:
>>>
>>> I believe this PR is ready for final review. Please let me know if you have any concerns.
>>>
>>> https://github.com/apache/whimsy/pull/94
>>>
>>> Thanks,
>>>
>>> Craig
>>>
>>> Craig L Russell
>>> clr@apache.org
>>>
>>
>> Craig L Russell
>> clr@apache.org
>>
Craig L Russell
clr@apache.org
Re: roster-emeritus PR #94 is ready for final review and some
improvements suggested
Posted by sebb <se...@gmail.com>.
On Mon, 6 Jul 2020 at 18:14, Craig Russell <ap...@gmail.com> wrote:
>
> Just one final observation.
>
> The emeritus work flow once this PR is merged:
>
> Member decides to go emeritus, navigates to their profile, and clicks (request emeritus). This generates an emeritus request document and sends mail to secretary.
>
> Secretary receives the mail, reviews the request, and files it in emeritus-requests-received, and sends mail to the member.
>
> Ten days (or so) elapse.
>
> Secretary remembers that there is a pending emeritus request, navigates to emeritus-requests-received, reviews the documents there, calculates the effective date, and then navigates to the member's profile, double clicks Member status, and clicks (emeritus).
>
> This can be improved:
>
> 1. The Member status box to (request emeritus) could directly put the request into the proper place in emeritus-requests-received and send mail to the member acknowledging the request. Secretary does not need to be involved at this phase. Member could still rescind the emeritus request without getting secretary involved.
>
> 2. The secretary workbench could scan the emeritus-requests-received along with the incoming mail and post a separate list of things to do if there are any pending emeritus requests. If secretary then examines the emeritus request document, actions could include (emeritus) which would then do what Member status does today.
>
> WDYT?
Member may no longer have access to their password, so it must be
possible for them to email Secretary instead of using Whimsy.
> Craig
>
> > On Jul 4, 2020, at 2:17 PM, Craig Russell <ap...@gmail.com> wrote:
> >
> > I believe this PR is ready for final review. Please let me know if you have any concerns.
> >
> > https://github.com/apache/whimsy/pull/94
> >
> > Thanks,
> >
> > Craig
> >
> > Craig L Russell
> > clr@apache.org
> >
>
> Craig L Russell
> clr@apache.org
>