Looking at the history of emeritus requests, there are a number of request formats that we have accepted, including scribbled notes captured in jpg format, emails saved as .eml, emails saved as text, pdfs, pdfs with associated .asc signatures, etc.
To accommodate all of these seems beyond the scope of this project. Would it be ok if we restrict full tool access to requests made via the self service whimsy roster tool? Then, we can "simply" look in the document/emeritus-requests-received for the specific file named <full-name>.txt which can be parsed for the date submitted. The member who wishes to go emeritus can use the roster/_self_ page, double click on Member status, click "request emeritus status", click (Submit) and be done. This will send the filled form to Secretary for processing. If they change their mind within 10 days they can return to the roster/_self_ page, double click on Member status, click "withdraw emeritus request" and be done. This will send a message to Secretary withdrawing the emeritus request. This work flow still requires Secretary to acknowledge and handle emeritus requests, which I consider to be A Good Thing. And Secretary can still handle random requests for emeritus just like today, although once we advertise the new way, I cannot imagine anyone choosing to scribble a note and take a picture to send to Secretary. WDYT? Craig > On May 5, 2020, at 2:29 PM, Craig Russell <apache....@gmail.com> wrote: > > I'd like to see the full current documentation on the emeritus work flow. > Here's what I understand: > > User fills emeritus request, signs, and sends email to Secretary. > > Secretary uses whimsy workbench to file the document under > documents/emeritus-requests-received > > At least ten days elapse > > A miracle occurs and the document is moved from > documents/emeritus-requests-received to documents/emeritus; > foundation/members.txt is updated; anything else happen here? > > The miracle should be documented for future secretary and assistant. > > How about here: https://whimsy.apache.org/secretary/workbench/HOWTO.html > <https://whimsy.apache.org/secretary/workbench/HOWTO.html> > > Thanks, > Craig > >> On May 4, 2020, at 5:05 PM, Craig Russell <apache....@gmail.com >> <mailto:apache....@gmail.com>> wrote: >> >> Double clicking on the roster member status enables a menu with options: >> move to active >> move to deceased >> move to emeritus >> >> To add "request emeritus" and "rescind emeritus request" I need to know >> whether there is already an emeritus request pending. >> >> This could be done by having the committer.member.status be something to >> indicate that there is a pending emeritus request. >> >> Currently the committer model includes the member status: >> committer.member.status >> Values are strings from the section header under which the member is listed. >> >> I'll need a new status to accurately reflect the status as pending emeritus >> (the 10 day period between receipt of the Emeritus request and the action to >> make them Emeritus). >> >> Currently headers are >> Active (Voting) Members >> Emeritus (Non-voting) Members >> Deceased Members >> >> We could change the foundation/members.txt to add a new header >> Pending Emeritus Members >> >> This would change the secretary workbench tool processing. >> >> Or we can modify whimsy/member.rb to look at the pending emeritus request >> directory. This would probably break the model because currently it only >> uses the members.txt file. >> >> Or we can modify the file that delivers the member information to the web >> page to look up the documents/emeritus-requests-received file corresponding >> to the member and stuff a boolean pending-emeritus into the payload. >> >> Which is the least worst alternative? Something I haven't thought of...? >> >> Craig >> >>> On May 3, 2020, at 4:57 PM, Sam Ruby <ru...@intertwingly.net >>> <mailto:ru...@intertwingly.net>> wrote: >>> >>> On Sun, May 3, 2020 at 7:22 PM Craig Russell <apache....@gmail.com >>> <mailto:apache....@gmail.com>> wrote: >>>> >>>> I'd like to start with something that should be trivial: >>>> >>>> When the user presses "move to emeritus" or "deceased" the action is >>>> immediate. I'd like to change these buttons to raise a dialog box with >>>> (submit) and (cancel) buttons. In general, this is my own preference and >>>> better UX and I think much less dangerous. >>>> >>>> Hints for me how to convert the button to a dialog? RTFM with manual page >>>> links are a fine answer. >>> >>> Here's the manual: https://getbootstrap.com/docs/4.0/components/modal/ >>> <https://getbootstrap.com/docs/4.0/components/modal/> >>> >>> The short version is that you define a form, add a number of bootstrap >>> defined class attributes (example: "modal") and include it in your >>> page. Initially such forms will be hidden. Then you add a number of >>> attributes to your button (data-toggle="modal" data-target="#...") >>> where data-target identifies which form to show when the button is >>> pressed. >>> >>> Here is an example of a modal dialog in the roster tool: >>> >>> https://github.com/apache/whimsy/blob/master/www/roster/views/confirm.js.rb >>> <https://github.com/apache/whimsy/blob/master/www/roster/views/confirm.js.rb> >>> >>> Here is where a number of hidden forms are included in a page: >>> >>> https://github.com/apache/whimsy/blob/bacab15aca3c996950c458279ca3a78a470611ad/www/roster/views/pmc/main.js.rb#L218 >>> >>> <https://github.com/apache/whimsy/blob/bacab15aca3c996950c458279ca3a78a470611ad/www/roster/views/pmc/main.js.rb#L218> >>> >>> Here is an example of a button that causes a previously hidden form to >>> launch: >>> >>> https://github.com/apache/whimsy/blob/bacab15aca3c996950c458279ca3a78a470611ad/www/roster/views/pmc/main.js.rb#L64 >>> >>> Note: these concepts are independent of whether the application is >>> coded in Ruby or Node.js. >>> >>>> Next I'd work on adding a button (request emeritus) with a dialog box that >>>> shows the form. See below for details. >>> >>> Cool! >>> >>>> Thanks, >>>> Craig >>> >>> - Sam Ruby >>> >>>>> On May 3, 2020, at 2:34 PM, Sam Ruby <ru...@intertwingly.net> wrote: >>>>> >>>>> On Sun, May 3, 2020 at 5:06 PM Craig Russell <apache....@gmail.com> wrote: >>>>>> >>>>>> Next level of architecture: >>>>>> >>>>>> Most of the work should be done in the front end with a bit of help from >>>>>> the server. What we need from the server are: >>>>>> >>>>>> GET: given the apache id, return the full name, status (boolean: >>>>>> emeritus), the complete document if already filed under >>>>>> emeritus-requests-received >>>>>> >>>>>> POST: apache id, full name, filled emeritus form (if new request), >>>>>> rescind-requested (boolean) >>>>> >>>>> That approach sounds like it would fit well with the current roster >>>>> tool. If you are a member and you go to >>>>> https://whimsy.apache.org/roster/committer/__self__, you will see what >>>>> forms are on file, your membership status, etc. If you go to another >>>>> individual, you will see their status, for example: >>>>> https://whimsy.apache.org/roster/committer/stefano >>>>> >>>>> At the moment, people in the secretarial team can click on "membership >>>>> status" and reveal buttons that say "move to active" and "move to >>>>> deceased". >>>>> >>>>>> So what technology seems most suitable? Node can handle the http >>>>>> requests if we have a service running. Javascript can do the UI in the >>>>>> browser. How to glue all of this together? >>>>> >>>>> If the port of the board agenda tool goes well (and current signs are >>>>> promising), then we can discuss whether to do the secretarial >>>>> workbench or the roster tool next. Or perhaps we could have teams >>>>> working on the ports in parallel. >>>>> >>>>> Meanwhile, the Ruby codebase is the better starting point. >>>>> >>>>> I would suggest as a first task, adding a link to emeritus forms. >>>>> >>>>>> Craig >>>>> >>>>> - Sam Ruby >>>>> >>>>>>> On May 3, 2020, at 7:22 AM, Craig Russell <apache....@gmail.com> wrote: >>>>>>> >>>>>>> We will create a new script at members/emeritus.cgi that will use a >>>>>>> file template [1] at a member-accessible location. This script will be >>>>>>> linked from the Members whimsy page. >>>>>>> >>>>>>> The script will have three entry points: >>>>>>> Member in good standing >>>>>>> Emeritus request has been submitted >>>>>>> Emeritus Member >>>>>>> >>>>>>> Member in good standing: >>>>>>> Emeritus status will be described, and a button enabled: >>>>>>> (Prepare emeritus request) >>>>>>> >>>>>>> When the button is pressed, a window pops up with the Emeritus Request >>>>>>> form filled from the member's information and the local timestamp >>>>>>> (year-month-day hh:mm:ss <timezone> <+/- offset>) and at the bottom of >>>>>>> the form two buttons: >>>>>>> (Submit emeritus request) >>>>>>> (Cancel) >>>>>>> >>>>>>> When cancel is pressed, the popup window disappears, and the original >>>>>>> page redisplays. >>>>>>> When submit is pressed: >>>>>>> the filled form is filed under emeritus-requests-received >>>>>>> email is sent to secretary with a copy of the form, cc: the member >>>>>>> >>>>>>> Emeritus request has been submitted: >>>>>>> Information about the emeritus request (timestamp) is displayed, and a >>>>>>> button enabled: >>>>>>> (Rescind emeritus request) >>>>>>> >>>>>>> When rescind is pressed, a window pops up with the submitted Emeritus >>>>>>> Request and at the bottom of the form two buttons: >>>>>>> (Submit rescind request) >>>>>>> (Dismiss) >>>>>>> >>>>>>> When dismiss is pressed, the popup window disappears and the original >>>>>>> page displays. >>>>>>> When submit is pressed: >>>>>>> the file is moved to emeritus-request-rescinded >>>>>>> email is sent to secretary stating that the request was rescinded, cc: >>>>>>> the member >>>>>>> the Member in good standing page displays. >>>>>>> >>>>>>> Emeritus Member: >>>>>>> Emeritus status is described and a button displays: >>>>>>> (Request reinstatement) >>>>>>> >>>>>>> When request is pressed, a window pops up with text stating that the >>>>>>> members wishes to reinstate membership and two buttons: >>>>>>> (Submit reinstatement request) >>>>>>> (Dismiss) >>>>>>> >>>>>>> When dismiss is pressed, the Emeritus Member display is shown >>>>>>> When submit is pressed, email is sent to secretary requesting >>>>>>> reinstatement, cc: member. >>>>>>> >>>>>>> Comments? >>>>>>> >>>>>>> Craig >>>>>>> >>>>>>> [1] >>>>>>> Emeritus Request >>>>>>> >>>>>>> Dear Apache Secretary, >>>>>>> >>>>>>> Please change my status to emeritus. >>>>>>> >>>>>>> This request will be effective ten days after receipt. Once effective, >>>>>>> I understand that I will no longer be counted for quorum purposes at >>>>>>> Members Meetings, and I will no longer be able to vote at Members >>>>>>> Meetings. >>>>>>> >>>>>>> I understand that my privileges to review the foundation records and >>>>>>> subscribe to members mail lists will continue. If I would like to become >>>>>>> active again, I will send email to secret...@apache.org requesting >>>>>>> reinstatement, and my request will be voted on at the next members >>>>>>> meeting. >>>>>>> >>>>>>> >>>>>>> Apache id: __________________________________________________________ >>>>>>> >>>>>>> Full name: __________________________________________________________ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Signed: __________________________________ >>>>>>> >>>>>>> >>>>>>> Date: ____________________ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Craig L Russell >>>>>>> c...@apache.org >>>>>>> >>>>>> >>>>>> Craig L Russell >>>>>> c...@apache.org >>>>>> >>>> >>>> Craig L Russell >>>> c...@apache.org >>>> >> >> Craig L Russell >> c...@apache.org <mailto:c...@apache.org> >> > > Craig L Russell > c...@apache.org <mailto:c...@apache.org> > Craig L Russell c...@apache.org
