On Thu, Oct 20, 2011 at 12:51 PM, Dave Fisher <[email protected]> wrote: > > On Oct 20, 2011, at 9:20 AM, Rob Weir wrote: > >> On Thu, Oct 20, 2011 at 11:48 AM, Dave Fisher <[email protected]> wrote: >>> Hi Rob, >>> >>> This is excellent. >>> >>> On Oct 20, 2011, at 7:57 AM, Rob Weir wrote: >>> >>>> On Wed, Oct 19, 2011 at 4:11 PM, Andrea Pescetti >>>> <[email protected]> wrote: >>>> <snip> >>>> >>>>> I would turn the post you describe into a warning that the mailing list >>>>> address will change, including all information about Apache but not >>>>> requiring users to take action. I volunteer to consolidate the 12 lists >>>>> into >>>>> 3 and to subscribe users to the right ones (of course, being "project >>>>> owner" >>>>> of it.openoffice.org, I have a list of all subscribers to the 12 lists). >>>>> >>>> >>>> I did an experiment on how we can subscribe users to the mailing list >>>> automatically. I looked just at the technical aspect of this. I did >>>> not look at the legal or policy implications. >>> >>> I'm not a lawyer, but if a user has to approve the new subscription that >>> may be enough to meet even the highest privacy requirements. >>> >>> Next steps if we were to proceed: >>> >>> (1) Getting the emails from Oracle. >>> >> >> That may not be possible. It depends on how Oracle understands the >> ToU for the legacy lists and relevant data protection laws. >> Corporations tend to be conservative and risk-averse, I do not think >> they would make this data available to us. > > You are making an assumption. If we asked for only the map of OOo to real > emails so that we can handle the retirement of the forwarder in some way > other than the most precipitous (goes away when the OOo MX moves away from > Oracle) we might have a chance. I suppose someone will need to ask Andrew > Rist. >
My pessimism based on previous conversations should not deter you, if you want to give this a try. >> I was speaking only to the technical steps that someone might take. > > Concrete abilities are good to discuss. I thought you were leading us > somewhere. > >> In any case, I look at this a little differently. We don't need pure >> numbers. We're not looking for passive viewers. If someone is so >> disengaged that they are unwilling to subscribe to a new list, then >> they are probably not going to be active project members. And if they >> find using mailing lists difficult, then maybe we should be pointing >> them to the phpBB forums, as an easier interface to use? And for >> ourtreach where we are looking to get the message out to the maximum >> number of users, then we should be looking at social media; our blog, >> Twitter, Facebook, etc. > > I don't want to bikeshed on Social Networks and ML vs. Fora, I want to focus > on what is going to actually happen to the OOo MX and ML infrastructure. > Focus is good. I'm focusing on the mailing lists. >> >>> (2) Consider the @openoffice.org forwarder and that many subscriptions to >>> the OOo MLs use that address. If we had that email map even if scrubbed of >>> the name then we can apply that transformation as well. >>> >> >> The email forwarding service is something entirely different. I'm not >> touching that at all in my proposal. It is an independent migration >> topic. As far as I can tell no one has volunteered to do that. > > So, you have no real plans to implement re-subscription? Or, if you do you > don't have a problem resubscribing people with emails addresses that are > going away in another month? > Go back and read my proposal. It never mentioned auto-subscribing people. I mentioned the technical details of moderator-initiated subscriptions merely as a follow up to a side proposal that Andrea had made for the Italian lists. > >> >>> The subscribe email sent would then use the personal email. >>> >>> The list of OOo emails would be useful for sending warnings that these >>> "vanity" ids are going away. >>> >>> It would be great to have a single message about the OOo MX transition. >>> >> >> If there is consensus on how we are treating the email forwarder, we >> can certainly mention that in the post to the lists. But even if we >> don't have an answer on this yet, we can link to a "migration update" >> page that can be kept current with our high-level status of interest >> to the wider ecosystem. > > Whatever we say about the OOo ML and MX transition needs to be based in fact > and not assumptions. > It will be based on consensus, and consensus may be based on assumptions. In any case it will be on the wiki. Edits will be welcome. >> >>> Of note, [email protected] is being kept. Are there other community MLs on >>> OOo that should be kept? That's part of your inventory ;-) >>> >> >> I'm not touching private lists, at least not initially. I'm looking >> only at the most-used lists, maybe the top 50 community lists or so. >> We can iterate. We don't need to do it all at once. > > There will be community lists in addition to securityteam@ that will need to > be considered. > The lists are general of three kinds: 1) Project related lists, for people who are working on core product functions, dev, qa, translation, marketing, etc. These naturally fit into the existing ooo lists, once we have the marketing list created. We can add more in the future, if ooo-dev gets a drastic increase in traffic. We balance community inclusiveness with focus. We're already have the 2nd highest traffic list Apache-wide. At some point we may need to look at things like ooo-doc or ooo-l10n. But I think we should start of with the project related lists going simply between ooo-dev and ooo-marketing for now. 2) User lists -- and this includes the "discuss" lists and their variations in a variety of languages. These are end users, less adept at mailing lists. We'll need some care in migrating these lists. I'll have another note on this. 3) "Utility" lists, generally one-way broadcasts of source control, issue tracker notifications and similar. I propose that these not be migrated. > Given the repeated warnings we are getting about Oracle imminent removal of > some resources. I think we are going to need to execute a plan that > encompasses what happens to all of the OOo MX at once and in a coherent > manner. > My grandmother used to say, "Spit in one hand and wish into the other and see which one has more". I'm volunteering to do the work on part of this effort, the part that is related to the mailing lists, a part that interests me and which I think is important. That does not preclude anyone else from volunteering to do other parts. But it will take more than just wishing. > Regards, > Dave > >> >> -Rob >> >>> Regards, >>> Dave >>> >>>> >>>> Moderators of Apache lists can subscribe new users to the list, by >>>> sending a specially addressed email to the list manager. For example, >>>> to subscribe [email protected] to this list, you would send an email to: >>>> >>>> [email protected] >>>> >>>> Note the @ in the address is replaced by an = >>>> >>>> A moderator can do the above, but this still will generate a >>>> confirmation email, to [email protected], in English: >>>> >>>> >>>> ----------------- >>>> >>>> "Subject: confirm subscribe to [email protected] >>>> >>>> Hi! This is the ezmlm program. I'm managing the >>>> [email protected] mailing list. >>>> >>>> I'm working for my owner, who can be reached >>>> at [email protected]. >>>> >>>> To confirm that you would like >>>> >>>> [email protected] >>>> >>>> added to the ooo-dev mailing list, please send >>>> a short reply to this address: >>>> >>>> [email protected] >>>> >>>> Usually, this happens when you just hit the "reply" button. >>>> If this does not work, simply copy the address and paste it into >>>> the "To:" field of a new message. >>>> >>>> or click here: >>>> >>>> mailto:[email protected]"; >>>> ----------------- >>>> >>>> So with the moderator rights available to us now, we can't do a fully >>>> automated sign up of existing list members, even if we had resolved >>>> the legal and policy issues. I don't know if there are other, >>>> administrative functions in ezmlm that could be used, by Apache Infra, >>>> to more fully automate this. >>>> >>>> -Rob >>> >>> > >
