Actually adding gstein this time. - Sam Ruby
On Wed, Sep 21, 2016 at 10:17 PM, Sam Ruby <ru...@intertwingly.net> wrote: > 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
