cc += gstein On Wed, Sep 21, 2016 at 9:55 PM, Stian Soiland-Reyes <st...@apache.org> wrote: > Did this conclude..? Just in case it didn't, here's my +1 as well to > make podling membership be in proper LDAP groups; with email > notifications to private@podling as you mention.
This did not conclude, but you picked an opportune time to resurrect this thread with Greg joining the infrastructure team. In fact, I was planning to restart this thread for exactly that reason; thank you for doing it. My assessment previously was that there wasn't enough demand at the time to overcome inertia. This change will undoubtedly break things temporarily, but nothing that can't be fixed quickly. > (I am lucky enough to have faced the asf-authorization-template a > couple of times :) ) Join the club. :-) The current process sucks, doesn't it. :-) > Ensuring people.apache.org is updated would also make it easier for > podlings to refer to a canonical list of who are their members; which > would work somewhat the same way after graduating. That's part of the discussion I would like to have. I'm proposing that members of the podling can update the group. Currently only PMC chairs can modify PMCs. And furthermore, PMC chairs can modify *any* PMC, not just the one(s) they chair. I'd like to change this so that PMC members can modify their own group. And I believe that the increased notifications that this tool will provide will enable proper oversight. I also believe this to be fully in line with the President's (Ross's) desire to enable self-service. But a change of this magnitude to the way that we operate is something that requires a critical mass of support. Thanks for lending your voice to this discussion. > Letting podling members modify the group themselves is good (as you > said the worst they can do is add another committer), as long as we'll > keep the account creation process under the hands of ASF Members (as > it is now). ASF members and officers. By the way, if you ever want to submit an account request, you might want to try https://whimsy.apache.org/officers/acreq/; it loads much faster than https://id.apache.org/acreq/; if you like it, spread the word. - Sam Ruby > On 2 September 2016 at 18:52, Sam Ruby <ru...@intertwingly.net> wrote: >> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament <johndam...@apache.org> wrote: >>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby <ru...@intertwingly.net> wrote: >>> >>>> The first stage would be migrating existing lists to LDAP. This will >>>> require some small changes to whimsy and the phone book application. >>>> The whole effort will only take a few hours and be spread over a few >>>> days elapsed time. >>>> >>>> To prepare, we will need to decide who gets to modify these lists, and >>>> who gets notified. I propose that members of podlings be able to modify >>>> the list, and the private list associated with that podling be notified >>>> on changes. Alternate choices would include mentors for the podling, or >>>> the IPMC. Given that notification facilitates oversight, I encourage >>>> this to be pushed down to the podling, but will go with whatever the >>>> consensus turns out to be. >>> >>> My vote would be for mentors to be able to do this. The podlings don't >>> know enough yet to manage this on their own. I would be concerned of >>> missed process steps if the podling themselves could do it. >> >> See Mark's comment, and my response to it. >> >>>> The second stage would be to define an interface for adding (and perhaps >>>> removing) podlings. This could be limited to the IPMC and the web >>>> interface could ensure that it is only possible to create entries that >>>> are present in podlings.xml. >>>> >>> >>> Could this lead to the eventual removal of podlings.xml ? >> >> It could lead to where-ever the IPMC wants to go. :-) >> >> My preference is that the canonical definition be in SVN, git, LDAP or >> some such, and that tools like whimsy remain only a convenient >> mechanism to update these definitions. >> >>> Does any of this have a relationship to projects.apache.org ? >> >> At a minimum, both would derive information from a common source. >> >> My understanding is that the focus of projects.apache.org is to >> provide a public-facing and read-only interface to this data. >> >> The whimsy roster tool would provide an authenticated read-write >> interface to this data. And a non-exclusive one. Other tools could >> be written that update that information. >> >> - Sam Ruby >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > > -- > Stian Soiland-Reyes > http://orcid.org/0000-0001-9842-9718 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
