Re: Logging All Public Project IRC Channels
On 01/27/2015 05:55 AM, Benjamin Kerensa wrote: > The justification is that we are doing it wrong by defaulting to > closed decision making where not everyone can transparently see all > the discussions we have in the project. > > Great post that talks about this discussion btw and the importance of open: > http://stormyscorner.com/2015/01/working-in-the-open-is-hard.html +1 to Ben's proposal. We should default to open, unless there is a significant reason not to. Same thing we do with mailing lists. If we have IRC channels that seem to host more personal discussions (I'm not aware of any), we could exclude them. We know that many people already log IRC Channels privately and anyway IRC technically has many more serious privacy issues already (eg. IP exposure). I don't want to maintain my own bouncer to log, so it would be great if I could browse logs from the channels I'm interested in and can't be 24h online. ~nikos ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On 1/27/2015 6:29 AM, Nikos Roussos wrote: On 01/27/2015 05:55 AM, Benjamin Kerensa wrote: The justification is that we are doing it wrong by defaulting to closed decision making where not everyone can transparently see all the discussions we have in the project. Great post that talks about this discussion btw and the importance of open: http://stormyscorner.com/2015/01/working-in-the-open-is-hard.html +1 to Ben's proposal. We should default to open, unless there is a significant reason not to. Same thing we do with mailing lists. If we have IRC channels that seem to host more personal discussions (I'm not aware of any), we could exclude them. I know of IRC channels that are used for personal discussion. Sometimes they're ethereal to discuss a situation occurring in another channel, some are more permanent. Some channels I'm in to do this are password protected (and I assume wouldn't be logged as they're certainly "private"), while others are "public", but we don't advertise it. * From (kind of) following this thread it seems that the argument really boils down to whether it should be opt-in or opt-out. (Not whether we should do it at all or not.) It seems most people believe it is useful information to have. I can personally attest that it is nice to be able to go back and find a conversation and have a permanent link to it. We've been doing it for years in #instantbird. --Patrick * As an aside, I don't think the answer is "OMG You shouldn't be having private discussions"! I actually view it as a very good thing to have more personal discussions. There are people I spend *hours* a day talking to on IRC (some of which I've never met), yet...it's natural that some conversations tend to become more personal as you get to know people. It's nice to not: 1. Gum up the channels we do consider public. 2. Be able to have deeper conversations that we might not want made public. 3. Can have a limited, trusted audience. ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On 2015-01-27 12:59 PM, Patrick Cloke wrote: From (kind of) following this thread it seems that the argument really boils down to whether it should be opt-in or opt-out. I'd intended this request to be only for product- and project-related channels, and even then to be opt-in. Blanket opt-out enrollment in anything doesn't really sound like us. - mhoye ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On 1/27/2015 1:12 PM, Mike Hoye wrote: On 2015-01-27 12:59 PM, Patrick Cloke wrote: From (kind of) following this thread it seems that the argument really boils down to whether it should be opt-in or opt-out. I'd intended this request to be only for product- and project-related channels, and even then to be opt-in. Blanket opt-out enrollment in anything doesn't really sound like us. - mhoye Mike, And that's how I took it, but it seems that it was taken to mean "Let's log everything on IRC" or (slightly less strong) "Let's log all channels". Opt-in logging essentially matches what we have now. --Patrick ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On Tue, Jan 27, 2015 at 10:12 AM, Mike Hoye wrote: > On 2015-01-27 12:59 PM, Patrick Cloke wrote: >> >> >> From (kind of) following this thread it seems that the argument really >> boils down to whether it should be opt-in or opt-out. > > I'd intended this request to be only for product- and project-related > channels, and even then to be opt-in. > > Blanket opt-out enrollment in anything doesn't really sound like us. > > - mhoye Opting-in is not defaulting to open for what it is worth it is making open optional. And we actually do opt-in quite frequently there are features that collect data in Firefox that are on by default... Our mailing lists archive by open by default and our bugs are open by default. ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On 2015-01-27 1:51 PM, Benjamin Kerensa wrote: On Tue, Jan 27, 2015 at 10:12 AM, Mike Hoye wrote: I'd intended this request to be only for product- and project-related channels, and even then to be opt-in. Blanket opt-out enrollment in anything doesn't really sound like us. - mhoye Opting-in is not defaulting to open for what it is worth it is making open optional. And we actually do opt-in quite frequently there are features that collect data in Firefox that are on by default... Our mailing lists archive by open by default and our bugs are open by default. Those are fair points, but we're talking about changing the (perceived) behavior of an existing system, not establishing the standards of a new one. In that context I don't think it's fair - or good PR! - to impose that change on participants, even if it it is to reinforce a standard we expect of ourselves. I would prefer to see a change like this preannounced, limited to product- and project-related channels at first, and opt-in thereafter. - mhoye ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On 2015-01-27 2:11 PM, Mike Hoye wrote: On 2015-01-27 1:51 PM, Benjamin Kerensa wrote: On Tue, Jan 27, 2015 at 10:12 AM, Mike Hoye wrote: I'd intended this request to be only for product- and project-related channels, and even then to be opt-in. Blanket opt-out enrollment in anything doesn't really sound like us. - mhoye Opting-in is not defaulting to open for what it is worth it is making open optional. And we actually do opt-in quite frequently there are features that collect data in Firefox that are on by default... Our mailing lists archive by open by default and our bugs are open by default. Those are fair points, but we're talking about changing the (perceived) behavior of an existing system, not establishing the standards of a new one. No, we are talking about codifying something in a policy. The status quo is that IRC conversations can be logged, not just by Mozilla but by anybody who is connected to the IRC network. In that context I don't think it's fair - or good PR! - to impose that change on participants, even if it it is to reinforce a standard we expect of ourselves. I would prefer to see a change like this preannounced, limited to product- and project-related channels at first, and opt-in thereafter. I'm having a really hard time parsing most of the conversation here. It seems that most people are under the false impression that IRC conversations are private by default. That is not the case. Even in password protected channels, a lot of IRC clients (mine included for example) log the conversations happening when they are connected to the network. ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On Tuesday 2015-01-27 13:40 -0500, Patrick Cloke wrote: > And that's how I took it, but it seems that it was taken to mean "Let's log > everything on IRC" or (slightly less strong) "Let's log all channels". Opt-in > logging essentially matches what we have now. I'd phrase it a little differently: Logging of public channels is opt-in but also substantially more encouraged than it is today. We should also strongly prefer having discussion that could lead to decisions affecting others to happen on logged channels rather than unlogged ones, absent reasons to the contrary. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On 2015-01-27 2:17 PM, Ehsan Akhgari wrote: I'm having a really hard time parsing most of the conversation here. It seems that most people are under the false impression that IRC conversations are private by default. That is not the case. That a user's expectations are based on inaccurate information doesn't change how the user feels when those expectations are violated. My only point is that this is a privacy-related thing, so while in this case the tech is easy - as you note, that work is already done! - let's get the user-perception part right too. - mhoye ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: proposed "commit access implementation" module
I've gone ahead and noted this change in the wiki: https://wiki.mozilla.org/Modules/Activities#Commit_Access_Implementation https://wiki.mozilla.org/Commit_Access_Implementation_module Marcia: I will let you fill in the "Peers" section as you see fit. Gavin On Tue, Dec 30, 2014 at 7:28 PM, Gavin Sharp wrote: > Currently, the process of obtaining Mozilla commit access is driven by a > loosely-defined set of trusted community volunteers who monitor new > requests in the relevant Bugzilla component (mozilla.org::Repository > Account Requests). > > In practice, this important job is currently performed largely by Marcia > Knous, with help from Josh Matthews, with Axel Hecht and Pascal Chevrel > helping for the requests related to l10n repositories. Reed Loden, Kyle > Huey, and I have also helped handle these requests in the past. > > I think it would be useful to have a module defining these > responsibilities, and clarifying ownership of the overall process. > > Responsibilities: > - monitoring the access request queue > - confirming that all access requests satisfy the requirements of the > commit access policy before being granted > - coordinating with relevant members of the IT team who are ultimately > responsible for setting up the accounts and providing access > - ensuring that the requests are dealt with in a timely manner, and that > the overall process is not too burdensome > > Explicitly out of scope: > - responsibility for defining the commit access policy itself, which is > already covered by the existing "Commit Access Policy" module ( > https://wiki.mozilla.org/Modules/All#Commit_Access_Policy) > > I nominate Marcia Knous to be the owner of this module. I think Josh > Matthews is a good candidate to be a peer. Given the amount of work > involved, it's probably a good idea to have additional peers as well, but I > think Marcia can own finding those trusted volunteers and make them peers > as she sees fit. I don't personally have a lot of time to dedicate to doing > this work on a regular basis, and I know Kyle and Reed are in similar > positions, but I'm willing to help out on an as-needed basis, and I bet > they are too. For requests related to specific focus areas (like l10n), I > suspect Marcia will continue to rely on Axel, Pascal and others for > assistance. > > Gavin > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
I am also for open by default, but I think that we also need to take human behaviour into account, not just the technical possibilities. I think given how Mozilla operates, publicly (not just for Mozillians) available logs would be akin to streaming every conference room over vidyo by default. This is possible and this would be incredibly transparent, and people miss a *lot* of decision making and discussion from not being in the same room. But, would people remember to change their behaviour to remember that they constantly have an audience? Is this the kind of behaviour change we want? Would people just move to a different venue to be able to talk before an idea is ready for an audience? Would we just need to revisit this conversation to demand logging of the new venues? Also, what do we do about people who want a "safe place" to discuss something before sharing with an audience? Do we push them out of the community? You shouldn't have to follow an IRC channel to stay up to date on decision making. I like the idea of being able to link to a relevant IRC conversation in a bug or in an announcement to make this easier. I agree that volunteers need to put some effort into participation, but spending hours watching meeting videos and sifting through logs is a net waste of time compared to taking good notes and announcing decisions. Having to sift through logs to find the needle in a haystack is still a form of obfuscation. How does someone know there is even something in the logs they want to see? How do they figure out where that information is? Again, I agree that project channels should be logged, I'm just saying that practically speaking, I don't know that this actually does a lot to make us effectively open. I don't think it helps people who aren't already following those channels to better follow the team or get more involved, and I think we need to think through the side-effects of a logged and public policy for somewhere that people see as contained and informal (whether consciously or sub-consciously). Regarding the bots, you can set a bot to only send a message to the same nick once, so I think that actually can be done properly. I was also on a bug ages ago to update the message you get when you connect to the server for the first time. This would also be a place to mention a privacy policy (if that wasn't already the plan). On Tue, Jan 27, 2015 at 2:46 PM, Mike Hoye wrote: > On 2015-01-27 2:17 PM, Ehsan Akhgari wrote: > >> I'm having a really hard time parsing most of the conversation here. It >> seems that most people are under the false impression that IRC >> conversations are private by default. That is not the case. >> > > That a user's expectations are based on inaccurate information doesn't > change how the user feels when those expectations are violated. > > My only point is that this is a privacy-related thing, so while in this > case the tech is easy - as you note, that work is already done! - let's get > the user-perception part right too. > > > - mhoye > > > ___ > governance mailing list > governance@lists.mozilla.org > https://lists.mozilla.org/listinfo/governance > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
Majken, This > Regarding the bots, you can set a bot to only send a message to the same > nick once, so I think that actually can be done properly. I was also on a > bug ages ago to update the message you get when you connect to the server > for the first time. This would also be a place to mention a privacy policy is what I had in mind, yes. Also, your point about open by default but overwhelmingly vast communication overload vs actually *understandable* organizational transparency are well taken by me. Having things like project meetings and good status reports and notes on the wiki is more important. That said, having the project channels be default-open and a sensible notification policy about that just seems prudent and mission-appropriate to me. Larissa > On Jan 27, 2015, at 13:52, Majken Connor wrote: > > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Logging All Public Project IRC Channels
On 27/01/2015 19:11, Mike Hoye wrote: On 2015-01-27 1:51 PM, Benjamin Kerensa wrote: On Tue, Jan 27, 2015 at 10:12 AM, Mike Hoye wrote: I'd intended this request to be only for product- and project-related channels, and even then to be opt-in. Blanket opt-out enrollment in anything doesn't really sound like us. - mhoye Opting-in is not defaulting to open for what it is worth it is making open optional. And we actually do opt-in quite frequently there are features that collect data in Firefox that are on by default... Our mailing lists archive by open by default and our bugs are open by default. Those are fair points, but we're talking about changing the (perceived) behavior of an existing system, not establishing the standards of a new one. In that context I don't think it's fair - or good PR! - to impose that change on participants, even if it it is to reinforce a standard we expect of ourselves. I would prefer to see a change like this preannounced, limited to product- and project-related channels at first, and opt-in thereafter. So, strawman (which IMO is reasonable): can we check irc.m.o for currently-public channels with 10 or more people in that are not currently being publicly logged, which are clearly project/product-related (rather than watercooler chat stuff), and ask channel owners for all of them if they would consider ensuring the channel is publicly logged? (where "No" is a valid answer to that request, assuming $reasons) Does that seem like a reasonable proposal to everyone, even if it doesn't go quite so far as to either not change anything on the one hand, or enforce that everything is logged on the other? ~ Gijs ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
