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 Thanks, Craig > On May 4, 2020, at 5:05 PM, Craig Russell <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 >> >> 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
