I think the processing is similar to Emeritus: - Stage 1: file the request, but leave an entry in the queue - Stage 2: when the withdrawal time expires, the secretary can use a button on the roster to update members.txt and perform any other required steps.
On Thu, 29 Aug 2024 at 12:29, Shane Curcuru <a...@shanecurcuru.org> wrote: > > Just to be clear: this is a Member who has asked the secretary to > withdraw from Membership entirely, as per 4.6, correct? > > https://apache.org/foundation/bylaws#4.6 > > sebb wrote on 8/29/24 5:15 AM: > > Not sure if there is a defined procedure for this, or which body gets > > to validate the process. > > > > My thoughts are: > > > > The personal details need to be removed from the main members.txt > > section, but do we need to record the removal elsewhere? I think it > > would be useful to keep a private record restricted to the Secretary, > > e.g. the document requesting withdrawal. > > We absolutely should keep at least a record of their original membership > data (including address, name, etc.) someplace restricted, along with an > explicit list of dates they were members, for historical purposes. > > > Remove from the LDAP members group > > > > They need to be removed from the members-notify mailing list; AFAIK > > that is for current members only. > > > > They can unsubscribe themselves from other mailing lists, but should > > they be automatically removed from members@ and members-announce@? > > Yes, if they are no longer a Member, they should not have access to any > private resources; thus they must be unsubscribed from those places > (along with board/operations, and other similar lists). > > This doesn't affect any of their PMC memberships or project work; > they're still a committer, and can still read private@ of any projects > they are on the PMC. > > -- > - Shane > Member > The Apache Software Foundation > > > > > On Wed, 28 Aug 2024 at 22:17, Craig Russell <apache....@gmail.com> wrote: > >> > >> Looks like it's a manual process, unlike Emeritus Request. > >> > >> Someone with tribal knowledge will need to handle this one. > >> > >> Craig > >> > >> Craig L Russell > >> c...@apache.org > >> >