Time for compassion and the Init GR
Early morning, Wednesday, November 19, the results of the GR on init system coupling will be announced. No result will make everyone happy. In fact, that morning, some of our developers, users and contributors will be really unhappy. I would be dishonest if I said I didn't hope to be happy and reassured that morning. I suspect we all hope that the project will agree with our position on this complex and emotionally intense issue and reassure us that our values are close to those of the project; reassure us that this is a place where we can safely work together. I don't know who, but I know that for some of the people I care about in the project--people whose opinion I value--that morning will bring disappointment, sadness, frustration and fear. I may well be one of those people. However, Wednesday November 19 and every day after, Debian needs to work together. Today, now, before the results are announced, we have an opportunity to extend compassion and empathy and remind ourselves of the spirit in which we'd like to work together. I'm hoping that we can all take a few minutes to gain empathy for those who disagree with us. Then I'm hoping we can use that understanding to reassure them that they are valued and respected and their concerns considered even when we end up strongly disagreeing with them or valuing different things. Towards that, I ask you to take a few minutes to consider how you will feel if the option other than further discussion that you least favor is selected by the project. Actually, for some of us, the prospect of months of further discussion of this issue itself is likely to have its own negative feelings. For the moment though, I ask that you focus on one of the other options. What do you feel? Disappointment that the project didn't value something important to you? Fear about whether Debian will meet your needs as an OS and community? Sadness? Frustration? Fear when you consider whether you'll be able to get your work done? What actions could other members of the project take to turn some of those feelings around without compromising their beliefs, changing their mind, or giving up on the values that are important to them? I'll answer this question for myself in a moment; if you cannot think of things that would help you, perhaps some of the things that would help me would also be valuable to you. If not, you could find someone you trust and value and work together to see what you could ask for to receive emotional care. It's almost certainly true that others in the project--people you have worked with over the years--will have similar feelings if their least favored option is selected. Some of those people probably disagree with you. I'd ask you to consider extending other members of the project the sort of care that will help you--the actions you were thinking about in the previous paragraph. My hope is that by doing so we can all treat each other with respect and value without compromising our positions. In many cases, it may make sense to extend that care now, to commit now to an attitude of care and respect even when we might be the ones needing that care in a couple of weeks. For myself, here are things that I'd really value in a situation where I'm feeling disappointed, sad and afraid that my values might not match the project's: * Not talking about these tradeoffs in terms of what's right and wrong, but acknowledging that different members of our project have different values. User choice isn't bad any more than combining software to reduce code size is bad. There isn't a right answer. As Russ has explained a number of times in the TC, on debian-vote and on his blog, this is about tradeoffs. I'm sure some people will be happy if the project's values are aligned with theirs. When they take that as far as saying the project made the "right decision" or rejected "bad options," they are not valuing the contributions of those who disagreed with them. * People who disagree with me taking the time to understand my position. "Hey, Sam, what you seem to be saying is this...for these reasons. Have I got it?" That is, people taking the time to make sure they understand me without trying to persuade me. I'm not asking for agreement, simply that I'm valued and my opinions are valued enough to read, understand and confirm that understanding. I feel reassured that someone took the time to consider what I had to say even if they came to a different conclusion. * When true, reassurances that we share common values even in situations where we disagree about how to balance tradeoffs. * Offers to work together/to listen to my opinions in future. "Hey, Sam, I realize the decision didn't go the way you were hoping, but I'm interested in figuring out how within the scope of what we did decide we can best address the concerns you had." I really hope that folks who value user choice will be willing to work with those
debian-boston-soc
Apologies for the debian-boston-soc mailing list going away. I changed infrastructure a couple of years ago and it made it a bit more difficult to host mailing lists. I'd be happy if someone else wanted to run a Debian Boston mailing list, and I'd be willing to make the effort to bring the list back if people would use it. It didn't get a lot of traffic. --Sam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149aaedc46f-fce6e4cb-71ec-49d6-b2e6-4848a148df5e-000...@email.amazonses.com
Systemd Discussions--The Good Parts
I've tried to slow down my rate of posting both because I've said what it was useful for me to say and because after the most recent IETF meeting I've been taking a vacation in Hawaii, meditating floating in the ocean and living in the moment laughing with joy as the salt spray soaks my body. I'll be flying back to the continental US shortly after the GR results are announced and it will likely be 36 hours after the announcement that I'll be done with flights, home, caught on on $day_job and back to Debian mail. However, I do have one thing it might be useful to say now. There have been some really amazing moments in this whole systemd discussion. There have been moments where I've been really proud to be part of debian and reminded that this is why I love this community; this is why I'm here. Sadly, there have been other moments too with more negative emotions. The first was reading https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=3410;bug=727708 . Many of us recognize that bug number, but that particular message was Ian's message "On Diversity." In that message he talks about how he wants Debian to be a place where each of us can come to work on our priorities and have an opportunity to try and succeed at what we believe as important. He wants Debian to be a community where we can be trying different approaches and where people have an opportunity to succeed even when others in the project don't (yet) see the value in your goals. I think we've all benefited from this. We had something we wanted to accomplish, and it wasn't clear we'd succeed, or sometimes even whether it was a good idea. However Debian was a place where we could try and see if it worked out. If we attracted other like minded folks and the idea proved good, we succeeded. If not, perhaps the idea floated into obscurity. I recently re-read this as I was writing a blog post about this discussion. I was jumping around my hotel room, filled with the joy of that vision. i think Ian's vision in that post is similar to what Joey talks about when he talks about the importance of iterating on decisions and refining things. I think it's similar to what Russ talks about when he points to Joey's message and talks about finding what's fun to work on and doing that. I think it's wonderful that even when people disagree with the approach very strongly, there can be so much that they do agree on. Joey's dislike of process and governance is very different than Ian's formal attention to making sure he correctly amends and then accepts/rejects his amendments to work within the formalism of our constitution. However, I would be unsurprised if they both have valued Debian as a place where people can work on what's important to them. Another Yes! moment was reading Russ's mail about the challenges of the TC decision--the one where he pointed out what it was like to make decisions you cared about with people you respected when there was a lot of emotional connection to the decision. You know, the one that got cited everywhere and that was probably a significant part of why we all rewarded Russ at debconf. It's great that Debian has folks like that, and I aspire to meet the level of compassion, empathy and commitment Russ showed in that post. When I got to the hack lab at Debconf this year, I met Josh Triplett for the first time. He was running around talking about the joys of systemd. It's safe to say that Josh and I have different values surrounding gentle, phased transitions. Josh seems to value having one simple way to do things. I was starting to wonder if "O, hey is that what the annoying systemd folks are like...I see why some people are frustrated." However, I wasn't sure; Josh was talking to some other folks who shared similar values. Fortunately later in the conference I actually got a chance to interact with Josh. We went to dinner, where Josh was trying to work with the ifupdown2 proponents to understand how their technology differed from/interacted with networkd. I was pleased that he cared about understanding others use cases and cared about helping explain the value of his proposed solution. On the walk back to the dorms, I talked to him about concerns resulting from some of his comments about kdbus. He had reasonable answers for all my concerns including discussions of HURD and KFreeBSD. He cared about the points I brought up and was willing to revise his approach when he ran into trouble. It's great to brainstorm with folks like that. You may not agree but the result will be stronger than either of you could get alone. Finally, there's the discussion between Josh and Ian in the bug about the libpam-systemd dependency. It was nice to see Josh and Ian working together to refine that decision to be accurate, and to be more clear. I think to move forward we'll need to see more of that cooperation between people who disagree strongly. I'm probably missing some other moments in all this where the community rea
Re: Interpreting the init system GR results
> "Russ" == Russ Allbery writes: Russ> I have a different perspective. Russ> I think we just had a GR in which the Debian developer Russ> community said that we, as a community, would like to work Russ> through all of the issues around init systems together, as a Russ> community, rather than having any one side of the argument win Russ> unambiguously and impose its views on those who disagree. I agree strongly when I read your message. I feel a thrill of excitement when I think about the challenge we've placed before ourselves, because I imagine a world in which we eventually turn this into a victory for working together and for respecting diverse views. I hope those of us who voted for option 4 rise to this challenge. Having asked to work together using our normal processes, I request that we work to make sure that the way we communicate and work together is up to that task. In another message, Matthias Urlichs wrote: >Too true. This GR does not have winners. We all lost. Not as a result of >this vote, bus because of the incessant arguing, trolling, and mixing up >of personal preferences and angsts with technical merits and bugs which >preceded and accompanied it. We choose whether we win or lose. There's been a huge sacrifice in terms of pain and energy spent. We today can choose whether that's a loss, or whether that provides energy to work together with respect and understanding. We can choose whether to turn all that pain into an nuanced solution to the technical issues better than anything that could fit on a ballot combined with a community that has greater confidence in its ability to work together. --Sam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0149cced8948-18db9e1f-e174-4eea-a20b-3db3e90c7f2a-000...@email.amazonses.com
major Changes to the TC?
> "Tollef" == Tollef Fog Heen writes: Tollef> As for Zack's point about this process being underway Tollef> already: yes, that's the point. If we want to change things Tollef> about the TC, let's put out a comprehensive proposal instead Tollef> of changing one thing now and another thing in six or twelve Tollef> months. hi. First, I have a conflict of interest here in that I've thrown my name into the hat as a potential TC member. Having disclosed that conflict, I don't think it's serious enough to preclude me participating in the discussion. Secondly, I'm not responding to Clint's proposal to remove the TC. If you're convinced that the TC doesn't have value, then now probably is the time to remove it before people spend time trying to figure out how to approach a significant chunk of feedback we've received. I want to be very careful about change, particularly change that requires a high bar (constitutional amendments qualify) to implement. The main reason is that I think we're better at refining process, better at trying incremental improvement than we are at predicting the impact and value of major changes. I think there's a lot of frustration with the TC process of late. We've seen several TC members (Russ, Don, Keith, perhaps more) express that frustration. We've seen several members of the project express frustration. I've seen several people call for more of a consensus process, for more trying to work together than for the kind of decision making we've seen lately. I've noticed these calls because they align well with how I think and work. It's probable that other directions have been suggested that I didn't take as strong of notice of because they are less natural for me. I think that revising how the TC works is something best done incrementally with the TC working with the project. I don't think we'll be able to codify a new way of working quickly. We might be able to quickly write down *what we're trying today*, and have that be an easily revised living document. However the whole point will be able to try things and adjust. I'm concerned that how the TC functions could significantly impact what selection procedure you want for a TC. I don't think revising those together in parallel will produce best results. Also, I don't think revising the selection procedure is likely to be a good way to achieve a TC that works best with the project; I don't think we could easily predict how the TC selection approach will impact style of interaction. I don't for example think there's a tie between popular election winners and good consensus builders as compared to appointed delegates. So, yes, I do actually think we'll get better results if we change one thing now and then later change a few things six months down the road. So, I urge us to evolve not revolt. Thanks for your consideration, --Sam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014a0d15e0f8-7911b174-15c9-4496-b6bc-cc5208b96036-000...@email.amazonses.com
Re: draft alternative proposal: fix problem at the root
> "Russ" == Russ Allbery writes: Russ> There's another alternative to using the CTTE, and my Russ> understanding is that this was generally the method used prior Russ> to the existence of the CTTE, but I'm not sure it's really any Russ> better. Russ> There are specific teams in Debian, generally delegates at Russ> this point, that sit at choke points and can effectively make Russ> decisions like this as part of the course of their duties. Russ> For example, for the init system decision, I suspect a lot of Russ> the pressure would have been on the d-i team to pick a Russ> default. In the past, the usual victim for many of our Russ> disputes has been ftp-master, since they can block archive Russ> uploads or eject things from the archive. For others (and I Russ> can recall some epic ones), it was the DAM. I remember back in my first years of Debian thinking that the TC wasn't very effective. Stuff would get brought to them and not really decided. Some folks (Ian's name springs to mind particularly but I don't recall without going back to mail from the 2004-2006 time frame) really made an effort to make sure that the TC responded to issues brought to it. The TC became effective in that it gave answers if you brought issues to them. Today, I think we have an opportunity to see if we can transform the TC into a body that's good at helping people make these sorts of decisions when there is conflict. I think it will be as much about mediation, about asking people to work together, about pointing out to people they are talking past each other, about asking people to reconsider their decisions with certain criteria in mind than about overriding people. I think that if we can do that well, it will be very valuable. I think it will also be very different than giving the power to the individual teams. I'd really like to see the TC be given an opportunity to try that sort of thing before we start doing major changes. --Sam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014a10905a0c-8344753f-e2ee-4a09-9f34-81fd73767e35-000...@email.amazonses.com
Re: About language specific package management tools
One huge advantage of teaching our package management tools to understand alternate package technologies and convert on the fly is that we can use the mirror networks of the language-specific packages. Unfortunately, we're fairly picky about licensing issues and legal distributability of packages. That's a significant value we add to Debian and it's really important. However, we'll probably find that if we tried to automate something we'd discover legal problems. We'd discover confirming DFSG status difficult if we tried and that there are probably packages out there our users want that really when you look at it aren't actually even redistributable. It's great that we add the value we do but we should not force that on our users. If our users are happy with CPAN or pip or whatever, we should give them access to all that software even if we cannot host it on our servers. For that and a couple of other reasons I favor having each user machine do the conversion rather than handling it centrally. Providing ways to do caching at an organization level and ways to package software that is important enough to bring into Debian both seem important to me. --Sam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014b2698cba1-b2e5ca2f-3a3a-4d09-ad10-b2d2c1ca849f-000...@email.amazonses.com
Re: Why are in-person meetings required for the debian keyring?
> "Nikolaus" == Nikolaus Rath writes: Nikolaus> However, it seems to me that meeting someone in person Nikolaus> isn't actually verifying the relevant identity here. My Nikolaus> trust in a Debian developer is not based on him holding a Nikolaus> particular legal name, it is in his history of Nikolaus> contributions. In other words: just because I'm sure about Nikolaus> someone's legal name, I wouldn't trust him to run code on Nikolaus> my computer. But if someone has been contributing to Nikolaus> Debian for 5 years with a specific GPG key, I'd probably Nikolaus> trust him to prepare a package no matter if the name Nikolaus> associated with the GPG key actually corresponds to some Nikolaus> legal identity or not. There are lots of types of trust involved. I definitely think past contributions is part of it. However, I also thing it's desirable that we have some probability of being able to engage a legal process if we needed to. Imagine someone intentionally uploaded some compromised software to Debian with the purpose of harming our users/turning debian machines into bots/etc. That's something we should not stand for, and being able to respond to that sort of thing in the legal system does have to do with a binding to a particular legal identity. An in-person meeting is neither necessary nor sufficient for that sort of legal binding, but I suspect in a number of cases it would help significantly. --Sam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014b7a8b3b86-34c1547c-c3bb-4d4c-8241-c782ef02d3fd-000...@email.amazonses.com
Re: Survey on Bug Tracking Tools
> "Dominik" == Dominik George writes: Dominik> On 08.06.2015 20:46, Florian Weimer wrote: >> Google services are quite popular among the FLOSS crowd at large. >> You might not see many Gmail posters on Debian mailing lists, but >> this is increasingly an anomaly. Dominik> Which is, at best, a serious illness. I'm really frustrated reading this. I'd like to share my frustration in hopes of seeking understanding and confirmation that we share the core value of working with a diverse set of contributors. I hope Debian is a community that can respect a diverse set of needs and beliefs. If you don't want to use Google Docs, I respect your desire there. However, I'd ask you not to judge others when their needs differ from yours. We don't even ask people to subscribe to free software as a moral stance to be part of this community. We ask people to uphold the DFSG and social contract *when they are working in Debian*. We don't ask them to agree that it is the right way, we simply ask them to uphold our community standards when working here. The DFSG and social contract do not judge what commercial services we use. Many members of our community care about various aspects of that. I want to live in a Debian where people who dedicate themselves to free software can work along side those who understand the value of the DFSG to Debian but make other choices in other parts of their work. I do not want to be part of a Debian where we judge those and push people away whose values we find wanting, even when they uphold our practices and social contract. --Sam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014dfa4f485b-36e25a71-f27d-492f-ba93-a0e86a1aaeca-000...@email.amazonses.com
What it means to be Debian
> "Dominik" == Dominik George writes: Dominik> b) BELIEF = Dominik> If any Debian contributor BELIEVES that the use of Google, Dominik> and the like, is a good thing, then the illness lies in the Dominik> divergence between their contribution and their values, and Dominik> in that case, I honestly do NOT respect that and consider Dominik> it harmful. OK. Thanks for sharing your opinion. This issue is important enough to me that I'd like to take a moment to share mine. I'm not trying to pursuade you. I really appreciate how you presented your position; you didn't try to say I was wrong, and you were honest and open even when there is disagreement. I am not judging you or trying to say you are wrong. We disagree quite strongly, but at least today, there's room for that. For myself, I've adopted software freedom as a fairly important value. I do use some non-free software and use somewhat more non-free services, but not in my software work, and I look for alternatives. However, far closer to the core of my being is a value for diversity, for connection, and for openness. Agreement on what a community does--things like the DFSG and social contract are essential for forming communities. However, insisting that people hold particular beliefs rather than that they uphold the standards of the community has affects I strongly disagree with. It tends to drive away people with interesting opinions and to stifle growth and evolution of the community. It tends to really bad politics, ideological purges, hate and fear about how you will be judged. I do not value those things. There are many reasons someone might support the DFSG besides belief in the global "rightness" of free-software. As an example, someone could believe in the commons. They want value for their effort. In the free-software commons the value is that when they contribute, they get to use the contributions of others. Yet, they might equally be happy in other areas to be paid directly for their value. I've worked with people coming from this viewpoint and exchanged great value. If you succeed in making this sort of belief in free software a condition of being part of Debian, you will drive me and probably others away. I suspect that personally I meet your requirements. However I wouldn't want to be part of such a closed community even if it would have me. I'd be sad if that happens, but I'd honor the change in the community. my reading of the current Debian is that I am welcome and that while a lot of us do value free software for itself, we are open to anyone upholding the DFSG and social contract. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014dfc632c8e-15f4c6fa-fd39-4d13-bb21-2c9f97f611de-000...@email.amazonses.com
Re: What it means to be Debian
> "Zlatan" == Zlatan Todoric writes: Zlatan> On the other hand - I do believe that Debian contributors Zlatan> should uphold Social Contract and DFSG as much as possible Zlatan> because if we don't push it forward and believe in it, then Zlatan> no one else will. I agree with the above. However no where in the social contract do we commit to using only free tools for our work. I can use Outlook to read my Debian mail. I can use IE to interact with db.debian.org if I like. I can send mail to the BTS from Apple mail.app or from the gmail website. I choose to do none of those things, but will vigorously defend others' right to do so. we also don't clearly indicate that we believe Debian should use free tools and services for project infrastructure. You can argue that is implied by "the system require the use of a non-free component," but I don't think that's very clear. I do think it's important that it be possible to buildand work on Debian using entirely free tools, and I think it is important that the Debian Project use free tools for its infrastructure and prefer/require services that are free software. I think we tend to do that. I think several of our key teams do that as policy. I don't think we've made a level of commitment like the social contract to do that. In general I would support making such a commitment to the community, but it would require careful wording and it would require looking at whether we need any exceptions where there are real gaps. As an example, I ssuspect a lot of the services where we have hardware hosted use proprietary service management software. I suspect the registrars and registries where we register our DNS domains use proprietary services. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014dfdf7db95-bb7839ff-c43b-495a-a752-20493b67337a-000...@email.amazonses.com
Re: What it means to be Debian
> "Bas" == Bas Wijnen writes: Bas> The above has nothing to do with beliefs. Beliefs are about Bas> people who believe that using non-free services is better for Bas> some ethical reason. They will say that even if a free Bas> alternative would be available, the non-free service is still Bas> better and so people shouldn't use the free service. I'm not Bas> talking about missing features, because those are in the realm Bas> of "needs". A belief in a non-free service means that they are Bas> of the opinion that free software is ethically (as opposed to Bas> technically) inferior. I believe that such a view is Bas> incompatible with the core values of our community. Here, I think we are in disagreement. I value communities that don't tell people what they must believe. I welcome people who believe that the network effects of large centralized services provide significant value and that the practical effects of running such a service mean it will be non-free, to Debian so long as they follow the social contract when they work on Debian. I also welcome the discussion about the tradeoffs and ethics that are common in our community. However, one of the things I value about our community is that our values ar expressed in terms of our actions, not our believes. We say in our social contract that we'll produce a free operating system and that our priorities (what we focus on when needs conflict) are users and free software. No where do we say what our users or contributors must believe. We even write text which I've always read as saying that we value working with people who have a variety of beliefs. To me that's all very important. So, I spoke in terms of needs not beliefs because I believe beliefs have very little place in what it means for me to be Debian, and I hope that is something that persists over time. --sam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014e69b3417f-00028b3a-799a-49fd-be7d-4d2d1f99d7d3-000...@email.amazonses.com
Re: "Do you want to mount the drive, 'cancel' or 'allow'?"
If someone is interested in working on some documentation, I found the pklocalauthority man page plus looking at the action files in /usr/share/polkit-1 helpful. the pklocalauthorityman page does actually have examples and I believe combining that plus the action names from the action files would allow you to figure out how to enable whatever you like. It probably would be helpful to write some documentation discussing how that all interacts with -libpam-systemd and what some options you have are if you decide not to have that in your stack. --Sam
Re: vmdebootstrap sprint report
Long term, how does this project relate to live-build. Is live-build going away, or are there different use cases where you'd want to use one vs the other? --Sam
Re: vmdebootstrap sprint report
> "Norbert" == Norbert Preining writes: >> only. It's scary to think that its intention is to also replace a >> tool like bootstrap-vz that has been used for years, is currently >> maintained and is pretty stable. Specially when not even >> mentioning this to the Debian Cloud Team. Norbert> Read up on recent - let's say - slightly surprising and Norbert> unconcerted forceful takeover of live-build. Norbert> It speaks stories about what has become possible in Debian. Hi. first, I really appreciate all the work that has gone into live-build, which I've used for years, and which I have the experience to appreciate. I' also appreciate the work that has gone into vmdebootstrap and debootstrap-vz, which I've never personally used. Speaking as someone who has used Debian images from a lot of different sources and someone interested in consistency, it would be good if we did work to get to a point where: 1) All these images are consistent. I think I want the same things from an image I install on a VM, an image I install in a private cloud and an image I install on a public cloud. I think I want the same thing out of a live image where I've removed live-boot and live-config. 2) As someone who ends up building cloud images for my business, building live images, and who has build installers and images for small derivatives, I'd really appreciate fewer rather than more tools. This is an area where I think it's important to be consistent and to spend the extra effort to get tools that work for everyone. Speaking as an individual member of the TC, I'd like to see us do that in a way that grows our project and empowers our contributors. It really really sucks to spend effort on a project and have your effort not acknowledged, or taken into account. For myself at least I find disagreement, especially when my input was considered, much easier to take than what feels like the lack of respect that comes from being ignored or discarded without being involved in the process. I fully realize that a simpler explanation for those feelings is sometimes that people didn't know about my efforts. It sounds like we have some important work to do here to reconcile some differences and get to a point where we're a project on this issue rather than a collection of disconnected teams and views. I think image creation is important enough where that is very much worth doing. --Sam
Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
As a member of the technical committee, I've grown increasingly alarmed as I think about the impact of the issues that come to us. Yes, we're giving answers. However, I think we are doing a lot of harm to the members of our community in the process, and I would like to explore whether we can do better. I've written a blog entry describing my concerns. It's on Planet, and you can see it at https://hartmans.livejournal.com/97174.html I've reached a point where I'd like to share my concerns and ask "anyone else feel similar? Anyone else want to work on solving this?" In thinking about my concerns I went over a list of issues that have come before the TC going back somewhat before the Systemd discussion. However, I did not perform any quantitative or statistical analysis. As you can see I also didn't share any discussion of specific issues. I'm not trying to persuade you I'm right. I am very interested in being exposed to your ideas about how one might think about this situation, and certainly exposing me to new ways of thinking is likely to change my opinions. But I'm not really interested in persuasion either incoming or outgoing at this point. I'm seeking shared interest. If we get to a point where we want to propose a specific change, we'll need to convince the project it will make things better. That's a ways down this road. signature.asc Description: PGP signature
Re: Bitcoin donations
> "Ben" == Ben Hutchings writes: >> And why would you refuse a way to submit donations that's >> convenient for some donors? Ben> [...] Ben> Mozilla tried it and the result was a net negative: Ben> https://fundraising.mozilla.org/bitcoin-donations-to-mozilla-17-days-in/ The link you site does not support the claim that it was a net negative. The link you site claims that sticking bitcoin donations *on the main donation form* was a net negative. Unfortunately because of the methodology we don't have a good idea why it was a net negative or whether that would apply to Debian. (This is not a criticism of the methodology which sounds great, just a fact) At least from the discussion on that post it sounds like accepting bitcoin donations was a net positive provided that they were isolated from other donations.
Re: Appropriate escalation (or non-escalation) re rude emails
> "Chris" == Chris Lamb writes: Chris> However, I do not believe one needs standing to do so and Chris> would highly encourage people to call out behaviour they feel Chris> is unacceptable, whoever they are or whatever flags they have Chris> in the Debian LDAP server. Chris> Indeed, this is probably more effective at changing the Chris> culture as it does not involve a paternalistic/authoritarian Chris> "telling off". Thoughts? In general, I think this is great. I have a few fbits of advice I'd offer: 1) I'd recommend being extra careful that such mails are clear, respectful and compassionate. Clearly explain what behavior you hope will change, why that would be valuable. Talk about the behavior on content not about the person. 2) Especially when there's area for disagreement make it clear what position you have in the project. Hi, I'm the DAM, and THIS MUST STOP NOW requires a different approach if you think the request to change is unreasonable than hi I'm a user and I hope everyone in the project THINKS THIS MUST STOP NOW. 3) Similar to 2. I don't think you can take off any hats you do have when sending such mails. If you have a role in our account, antiharassment, conduct, listmaster, moderation, or other related processes, you can't really ever give that up when talking to people about conduct. People will hear, and to some large extent should hear your message with the hat, even if you intend it without the hat. And so, I think you need to take the same level of responsibility and care for anything unofficial that you would for something more official, because it's subject to the same potential for abuse. --Sam
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
> "Russ" == Russ Allbery writes: Russ> Martin Steigerwald writes: >> Russ Allbery - 28.10.17, 16:13: >>> There wasn't *anything* "left out" of that discussion. >> In my opinion this is a pretty bold statement. >> If everyone has been heard, noticed, felt and valued, if >> everything has been covered, then why are we discussing it… yet >> again now? Russ> Those are not equivalent statements. In that sort of Russ> discussion, it is literally impossible to make everyone feel Russ> valued, since at least some people on each side will only feel Russ> valued if their preferred option is chosen. That's therefore Russ> not a reasonable thing to attempt to achieve; we can try to Russ> maximize the number of people who feel valued, but there are Russ> usually at least some people involved in this large and Russ> sprawling of a decision for whom "valued" is synonymous with Russ> "agreed with." For myself, I've found that if I work with people I can often get to a point where they feel valued even when there is disagreement. As you point out that's not true for some people and it is difficult even when it is possible. I was not planning on discussing systemd again. I am discussing how we handle conflict because I hope we can do a better job of helping people feel valued even when we do not agree with their technical positions. In the limit, I hope to do your literally impossible:-) Fortunately, I'd be thrilled and filled with joy to simply get closer to that limit. Helping create a culture where we have mechanisms to help ourselves separate value from agreement, and where we value using those mechanisms would delight me. I think even that is a hard ask, but I do not think it is literally impossible. --Sam
Re: Appropriate escalation (or non-escalation) re rude emails
>>>>> "Don" == Don Armstrong writes: Don> On Mon, 30 Oct 2017, Sam Hartman wrote: >> 3) Similar to 2. I don't think you can take off any hats you do >> have when sending such mails. If you have a role in our account, >> antiharassment, conduct, listmaster, moderation, or other related >> processes, you can't really ever give that up when talking to >> people about conduct. People will hear, and to some large extent >> should hear your message with the hat, even if you intend it >> without the hat. >> >> And so, I think you need to take the same level of responsibility >> and care for anything unofficial that you would for something >> more official, because it's subject to the same potential for >> abuse. Don> Taking care and responsibility is appropriate (and I believe Don> everyone in these difficult roles does so.) Don> However, taking the same level of care and responsibility would Don> necessitate running any message I send by all of the other team Don> members before sending it.[1] That would mean I'll never point Don> out sub-optimal behavior until it reaches a level which is bad Don> enough that it's worth wasting everyone else's time to craft Don> such a warning. [Usually after multiple complaints.] So, when you do that, it sounds like you're trying to duck accountability. It sounds like you're telling me that if I have a problem with your actions, I cannot complain about it as an listmaster action. And yet, since you are a listmaster, some day you may choose to act as a listmaster. And since it has a similar chilling effect on speech, I'm very uncomfortable with that approach. If I had to choose between you sending personal warnings that had no accountability and you only acting after reviewing with the entire rest of the team, I'd be more comfortable with the project in which you didn't send the warnings until they rose to the level where the entire team needed to be involved. But that seems a false dichotomy to me. It seems like you could act as an individual listmaster who has not reviewed things with the rest of the team. "It's my opinion as an individual listmaster that you are violating our code of conduct... If you disagree, you can talk to me or the rest of the listmasters..." By acting as an individual listmaster, you make it clear that I have a path for a second opinion: asking the other listmasters. But you also make it clear that if the community has concerns about the aggregate actions of the individual listmasters, we can also take that up with the listmasters. So, you can send mails promptly without seeking review, provided the other listmasters are OK with that. If they aren't, well, that's a fairly good sign you shouldn't do it as an individual either. --Sam
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by
Ian> Disagreement: Concerns about the Technical Committee"):
>> I am discussing how we handle conflict because I hope we can do a
>> better job of helping people feel valued even when we do not
>> agree with their technical positions.
Ian> You've perhaps heard me say this before, but I think the TC
Ian> process lacks structure and that if the TC set out the process
Ian> more formally, things might go less awry. (And also it would
Ian> involve less of an investment of energy by all the partipants,
Ian> particularly the respondents to a complaint.)
I thank you for presenting this again. This time, you focused more on
what you were hoping for out of the proposal rather than on your
preferred details, and I got a lot more out of it. It's easier for me
to start out thinking about goals, and you spent more time (or at least
I spent more time reading) about your goals in this version.
Ian> One of the most toxic things that can happen in any kind of
Ian> dispute is for there not to be a clear understanding of what
Ian> the rules are, within which the dispute will be conducted. Ie,
Ian> who is allowed to do and say what, and when.
I think it would be quite valuable for the TC to spend some time
documenting what people can expect.
I think it would be valuable to spend a lot of time thinking about how
we can avoid the need for a defensive reaction from people responding to
a complaint.
That said, I actually think in some cases we need to spend more energy
rather than less. Minimizing energy spent on the process is not one of
my goals. I think that the TC in particular may need to spend more
energy to have a chance of people feeling valued even when there is
disagreement.
Interestingly, the one area where I think conserving energy is important
is the one you call out: minimizing the energy people need to spend
responding to a complaint.
Even there, I think that in a case where the TC thinks it is likely to
ask a maintainer to make a change (or override the maintainer) it is
reasonable to expect the maintainer/respondant to spend enough time to
explain their position well enough that the TC understands it.
Ian> When people disagree about the metarules, community
Ian> disintegrates because people feel that not only are their
Ian> opponents disregarding their needs, but they are also playing
Ian> foul.
Yes.
Ian> I know that some people disagree, but I think that the TC
Ian> should take on much more of the trappings of other formal
Ian> dispute resolution mechanisms that we find in wider society.
Ian> Particularly, the TC should be more like a civil court or
Ian> tribunal.
Ian> Courts are of course stressful, but I think that stress is
Ian> usually the result of the underlying dispute.
There's a time in my life where I would have been in complete agreement
with you.
I've spent enough time working with dispute resolution processes that
work like courts or tribunals to have high confidence they wouldn't work
better than what we have.
As a distant third-party observer, I can look at a court transcript and
have a positive reaction. It's fair and just. All sides were
considered.
However, like in our process, courts do not optimize for the
participants feeling valued, for the participants feeling their concerns
were considered. I feel concerned thinking about us moving closer to a
court process, because I don't think it would address the concerns that
led to me writing this thread. I think that people would be very likely
to walk away from the process hurt and less likely to stay in our
community.
I also think the court emphasis on justice and "right" is harmful. As I
said in my blog entry, technical correctness is an important factor, but
I think it is a less important factor than maintaining our community.
However, because of who we are, we tend to emphasize technical
correctness. I think that our natural tendencies plus a court/tribunal
process would be a very bad combination in terms of compassion for our
community.
I do appreciate you taking the time to share your desire for clearly
defined expectations for what people can expect in the process.
I hope the project can do that for us both.
--Sam
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
> "Ian" == Ian Jackson writes: Ian> Thanks for your mail. I have trimmed vigorously the parts I Ian> agreed with :-). Thanks again for your mail. I also trim parts where I think we understand each other and seem to be in general agreement. I want to explicitly call out your analysis of how mailing list discussions can be problematic. I think that's a really important point to this discussion. I might choose to be less formalized in how I'd prefer to solve the problem. However I think you've highlighted that mailing list discussions are the wrong approach for the really thorny issues. One mechanism that is often helpful in cases where mailing list discussions add value is to summarize them going forward. I think we're very close to a point where it would be useful for me to prepare such a summary of this discussion. >> I also think the court emphasis on justice and "right" is >> harmful. As I said in my blog entry, technical correctness is an >> important factor, but I think it is a less important factor than >> maintaining our community. Ian> IMO injustice _itself_ undermines community. Ian> When you say you want to put "community" ahead of "justice", Ian> what I hear is that you want to put the opinions of some people Ian> ahead of others, because they might be hurt more if the Ian> decision goes against them, or because the are more important Ian> to the project somehow. Ah, thanks for explaining what you heard. That's not what i want to say at all. Also, I wouldn't even say I put community ahead of justice. I put community ahead of technical correctness. I also think court-style justice in our community would emphasize technical correctness. Justice as an abstract concept is not something I have simple positions on. Ian> After all, if we are not to put some people's opinions ahead of Ian> others, what we are left with is making decisions based on the Ian> merits, which is what I am thinking of as justice. This statement feels wrong to me. It's not obvious to me why it is true that the putting some opinions ahead of others is coupled to making decisions on the merits. I think there's possibly more to unpack there, although I'm not sure it's where we need to go to understand each other. I'd like to give some examples of cases where I think community is more important than technical correctness. * Some people's opinions do matter more than others on some decisions. The most obvious example of this is we have a culture of letting the people doing the work have huge latitude. It might be better overall if we picked a single scripting language for all Debian infrastructure, maaintainer scripts, development tools, archive software and the like. It's far more important to let the maintainers use the tools they prefer. It might have been great for the project to mandate debhelper a while ago. Just within the last year we've finally gotten to a point where policy recommends using debhelper in one circumstance. Again, we strongly prefer letting people doing work have flexibility. So often, the TC finds itself saying "you might even be right about the technical issue, but those folks actually doing the work get to pick in this instance." * Sometimes respect for work going on or for process is more important than technical correctness. You and I have disagreed about specific instances of the past. But for example I believe that if the policy editors are unsure whether they reached consensus on an issue, one significant factor that the TC needs to consider is whether the policy team did or did not reach consensus under their internal policies. I understand we disagree on the specifics here, and this is probably the wrong forum to rehash that. I do think that cases where respecting what other people are doing and respecting other processes are more important to community stability than technical correctness. * pSometimes it is more important to have maintainers or maintainer teams who are good at bringing in new people, mentoring, and the like even if it frustrates technical experts. If a particular maintainer team consistently has trouble dealing with their stakeholders, I think making changes to improve communication can be appropriate even if it decreases the technical quality of the team for a while. None of us are so good that we cannot be replaced, and yet all our contributions are valued. * Sometimes it is more important to get a decision made than to have the perfect decision. This needs to be balanced against manipulating the processes to prevent stakeholders from contributing etc. * Sometimes the cost of reviewing a decision can be higher than any potential gain. I can think of a number of TC bugs where a lot of frustration was spent overriding a maintainer and there was little benefit to our users. It was the right decision from a pure technic
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
> "Steve" == Steve Langasek writes: Steve> Hi Diane, Steve> On Thu, Nov 02, 2017 at 11:48:05AM -0700, Diane Trout wrote: >> I only just subscribed and only have read some of the discussion >> so this may be a bit off topic or already discussed. >> But I was wondering if the project has thought about explicitly >> encouraging mentoring in techniques for handling interpersonal >> conflict and helping members develop interpersonal skills? >> I know there's active research into managing team conflict, and I >> bet there are some Debian members who have been more effective at >> helping other team members that we might be able to learn from. >> I know we have methods to share technical skills via policies and >> best practices, but how do we identify and share useful social >> techniques? >> For instance I think active listening is a useful technique when >> trying to develop a consensus about a topic. >> (e.g. http://ggia.berkeley.edu/practice/active_listening#data-tab-how >> ) >> But I don't know how many others know about it and there would >> need to be some adjustment for a distributed team like Debian. Steve> Better skills for handling interpersonal conflict can never Steve> be a bad thing. However, the Technical Committee exists as a Steve> decision-making body of last resort, when consensus is not Steve> possible (because two parties have incompatible goals, or Steve> because discussion is not converging on agreement fast enough Steve> to matter). I think that Debian does need a decision making body of last resort. I personally think these communication skills are critical for such a body.
Summary: Concerns about the Technical Committee Process
On october 27, I posted a message to debian-project [1] pointing to a blog post [2] and starting a discussion of some concerns I have with the Technical Committee process. I am currently serving as a member of the TC; I'm speaking as an interested and knowledgeable individual. [1] https://lists.debian.org/msgid-search/tsl1sloxgyf@suchdamage.org [2] https://hartmans.livejournal.com/97174.html Martin Steigerwald[3] emphasized the importance of including non-technical considerations in our decision making. He also reminded us that conflict tends to produce a response of fight, flight, or stand still panicking. He said: >I agree with you that an important aspect is that each party receives the >chance to fully express their own position and be heard, seen, felt and >valued. So I think there needs to be a shift to see conflicts as something >positive and provide a safe space to express them. >Challenging for me is the answer to the question: How can such a safe place >look like in a community that is spread around the globe and can often only >connect via the means of the internet? [3] https://lists.debian.org/msgid-search/20398250.g3Mo30JhmK@merkaba Gunnar Wolf [4] said he thinks the TC works amazingly well today. He talked about how much the project has improved since the early days. It's a lot easier to be involved in Debian without such a thick skin. [4]https://lists.debian.org/msgid-search/20171028215011.j7ui7apd3oxyl...@gwolf.org Russ Allbery spoke about the difficulty of the problem[5]: >I think there are several principles that I suspect most people bring to >TC decisions. Certainly, I did. I think it may be helpful to look at >them and realize that they're *inherently* in conflict. In other words, >it's clearly possible to find cases (and we have found cases) where it is >literally impossible to satisfy all those principles at the same time. >We should always try to do better. >We should avoid expecting ourselves to be superhuman. I left out Russ's principles, but his entire message is recommended reading for anyone thinking seriously about this. [5] https://lists.debian.org/msgid-search/87r2tmua04@hope.eyrie.org >Russ also pointed out [6] that it is impossible to make everyone feel valued because some people on/only feel valued if their preferred option is chosen. Russ went on to explore the difference between listening to someone and agreeing with them and how hard it is to feel heard when the listener does not agree. [6] https://lists.debian.org/msgid-search/87o9ongun1@hope.eyrie.org Ian Jackson [7] proposed more formal structure in the TC process. He believes this would help especially for package maintainers (respondents) to a concern raised before the TC. He would like to see something similar to a tribunal/court process. >One of the most toxic things that can happen in any kind of dispute is >for there not to be a clear understanding of what the rules are, >within which the dispute will be conducted. Ie, who is allowed to do >and say what, and when. He said one of the most exhausting parts of the TC process is the limitless email discussions. Rules could limit this. He elaborated in another message [8]: >Unstructured mailing list discussions work reasonably well when >everyone feels that everyone else is on the same side, and everyone is >trying to understand the issues and feel they will be able to come to >a consensus, or at least a conclusion that everyone finds tolerable. >When things get more difficult, they become sprawling horrors. >Participants (quite understandably) feel the need to respond to >everything their now-opponents say. People feel under time pressure. >It becomes difficult to see the wood for the trees. Because the >parties are replying directly to each others' emails, there is ample >opportunity for misunderstanding, and all the escalations of minor >aggressions or poor word choices etc. into meta-disputes and anger. >I think it would be better if we asked participants to write a much >smaller number of longer and more comprehensive statements. In this message, Ian also outlined a list of factors that tend to be critical to TC decisions. [7] https://lists.debian.org/msgid-search/23032.45880.193971.897...@chiark.greenend.org.uk [8] https://lists.debian.org/msgid-search/23035.8784.982211.812...@chiark.greenend.org.uk Sam Hartman [9,10] said that it is important to work on reducing the defensive reactions maintainers have when they are asked to work with the TC. One part of that may be making it clear to maintainers if the process ever gets to a point where the TC is considering recommending a change. Some issues may be best addressed by helping a complainant understand the maintainer's position rather than by proposing any particular change. Sam also said that he's more concerned with
Re: Emeritus status, and email forwarding [and 1 more messages]
I think if we can find a way to manage it technically, allowing people to forward email would be a reasonable thing to do.
Re: On the Anti Harassment Team
I've seen other organizations call the antiharassment team an ombudsman team; perhaps ombudsteam might be more gender neutral though. I support the idea of changing the name and support the idea of letting the team decide on its name. I think rather than creating rules about delegates needing to refer less urgent matters to the team, we'd be better served by reminding delegates that they have that option. --Sam
Re: [Pkg-samba-maint] Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")
> "Thomas" == Thomas Goirand writes: Thomas> On 07/02/2018 01:14 AM, Josip Rodin wrote: >> The Debian social contract doesn't go into that much detail, to >> explicitly require keeping bugs open because they exist in >> practice -- but common sense and decades of precedent do. Thomas> I very much don't agree with the above. It is useless to Thomas> keep bugs open if they are not actionable. Bugs are Thomas> reminders for the maintainers of what they should do. If Thomas> they can't do anything, then it goes on the way to do useful Thomas> things, and it is best if they can be closed. I think that one of the key services we provide our users, and I think that this is implied very strongly by the social contract, is to provide a single uniform place for them to report issues, whether they are Debian specific or upstream. I think that when we take steps against making that work we decrease the value of Debian. That said, our social contract and constitution are quite clear that no developer is required to do any particular item of work.
Compassion For Those Worried Whether They are Welcome
> "Steve" == Steve McIntyre writes: Steve> For those trying to undermine it with statements like "I'm Steve> worried I'll be thrown out of Debian if I make a single Steve> mistake", please give it a rest already. These are basic Steve> principles on how we want all people to interact. If you make Steve> a mistake and do a bad thing, people will tell you and ask Steve> you to re-word, apologise, whatever. Steve, I agree that the code of conduct is important. I agree that some comments sound like they are undermining it or trying to rehash old arguments. I think that's draining. However, I'd like to take a moment to ask all of us to empathize with a common position. We've seen two people who made significant technical contributions expelled from the project. If you weren't paying a lot of attention, there were no obvious public signs that a process was underway. Many members of our project have never had to interact with a concerned DAM team or the sharper parts of our conflict resolution process. It's easy to worry that something will spiral out of control and you will be ejected from a community that you've put a lot of your heart into over the years. As you say, we're all human and we all make mistakes. As humans it is natural to feel insecure when you see something like this happen. Asking for reassurance that we'll be treated with compassion and empathy, given a chance to understand what is going on and heard when we speak our part of the story is natural. THESE INSECURITIES AND ASKING FOR THAT REASSURANCE DOES NOT UNDERMINE THE CODE OF CONDUCT. In this instance the insecurities are stronger because we're seeing people ejected and claiming that they were not given those chances and that they were surprised. To be clear, I am speaking from personal experience here. I think I've made positive contributions to the project, and I know people over the years have come to me when they had problems with what I did. If I think about it rationally, I have confidence that I'd be given a chance to learn and improve. And yet I looked at this and wondered if I'd someday find myself the subject of a surprise ejection. I was able to convince myself that my fear stems from how much I care about Debian. I do have confidence that even if there are trouble it can be worked through. For that matter, even if I found myself on the out, I could respectfully work to get back in and improve the process. Yet I firmly support the code of conduct and the importance of creating a safe space. I ask you to separate those who are trying to question the code of conduct from those who are seeking a very natural reassurance. Thanks, --Sam signature.asc Description: PGP signature
Re: Censorship in Debian
> "Scott" == Scott Kitterman writes: Scott> On Monday, January 07, 2019 07:06:28 PM Russ Allbery wrote: >> Miles Fidelman writes: > On the >> other hand, the IETF seems to do just fine - with a much larger > >> base of participants, and a lot more room for discussion and >> debate on > contentious issues. Global infrastructure, with >> distributed ownership, > lots of stakeholders, all held together >> by agreements, with the decision > processes open to pretty much >> anybody who shows up. The process puts > pretty much everyone >> else to shame - with lots to be learned from it. >> >> Speaking as someone who is a listed author on three published >> RFCs and chaired one IETF working group, I will take Debian >> process over IETF process any day, and find your description of >> the IETF pretty entertaining. :) >> >> Also, please note that many IETF participants are paid as part of >> their job to participate in the IETF. (We keep coming back to >> that.) That's true of some Debian contributors as well, of >> course, but I strongly suspect the percentage is lower. Scott> Similarly here (also three RFCs, but never chaired a working Scott> group). Scott> The IETF rough consensus model is very useful in many Scott> circumstances. I've used it successfully in multiple Scott> settings outside the IETF to great success in both moving Scott> technical work forward or driving decision making in a closed Scott> group to closure. It's not relevant to the problem a group Scott> like the Debian tech ctte has, however. Scott> Groups like the tech ctte have a different problem than an Scott> IETF working group. They have to make final decisions on Scott> things that affect the project as a whole, many of which are Scott> Scott> I'll also remind you that the IETF process as a whole is not Scott> whoever shows up. IETF working groups and IETF last call are Scott> open processes. IESG decision making is not. You can have Scott> all the working group consensus you want, if there are Scott> uncleared discusses against your draft, it's not moving Scott> forward. If you want a comparison, the tech ctte is a lot Scott> more like the IESG than an IETF working group. I've served on the Debian TC, I've served as an IETF working group chair, and I've served on the IESG. I think I have a fairly good handle on the differences between the IETF and Debian processes. The IETF process is good for developing a consensus where you want to focus on technical quality and where you have the right stakeholders as motivated participants. It requires a certain familiarity with consensus building to avoid a number of pitfalls. IT IS NOT TIME BOUNDED. It's great for situations where you are more concerned with the right decision than concerned with a decision within a particular time line. There are ways that you can try to control the time the IETF process takes, and it's even possible to do that if you can get a consensus on what the timeline is and on the technical tradeoffs that are in scope to achieve that timeline. Debian did not meet those conditions for the init system decision by the time it came to the TC. Debian had already done a lot of consensus building. We understood the scope of the problem, we understood some of the complexities surrounding having multiple init systems. TC members did do some additional excellent work curating and summarizing that knowledge (I was not on the TC at the time but was following the discussion). A consensus process would not have achieved the goal shared by most of the project of having a decision in time for the jessie release. I am unlikely to contribute to this thread again; like Ian I think init systems are off topic. --Sam
Re: Proposal: mediators
I think that rather than writing down a procedure like this it would be better to get some success cases of trying something along these lines. So, for example, I'd recommend that you and people who have similar views volunteer to be available as mediators. Once people use your services, and you have some practical experience then worry about writing it up. I am interested in mediation but my approach is very different than yours. * I think the emotions and feelings are more important than the facts * I am interested in working in cases where there is a desire to reach settlement * I think that your emphasis on facts and a statement of facts fails to account for some of the significant realities in dealing with conduct issues So, while I'm interested in mediation-like things, I am not interested in this project. I'm trying to find ways I can olunteer to help that are more aligned with my goals. However, I've seen others on discussions recently who may have goals aligned with yours. Debian is a community where we move forward by trying things out. Make your services available, let people know. Whether people are interested in using the services will be one gage of success. --Sam
Re: Censorship in Debian
Might I suggest that Miles and the rest of us have had as much of a meeting of minds as we can in the media of email and that this thread has drifted into noise? In my oopinion continuing would do more harm than good. --Sam
Re: Appeal procedure for DAM actions
While we're throwing around random wikipedia pages, I'd like to submit https://en.wikipedia.org/wiki/Sealioning With respect, I don't think Daniel's comments are a constructive addition to the discussion. Whether or not daniel was treated reasonably, I think that he's reached a level of bitterness/upset/disappointment that is not going to lead to constructive discussion. I think that Daniel's post would take a long time to respond to for a lot of us who have recently spent a lot of energy trying to work through some really hard issues. For myself, I'm not going to respond in substance, and I don't want silence to be taken as agreement. Here's why I don't think the post is constructive. There are a lot of reasons why you'd want to have rapid action for handling situations other than questions of technical competence. There are significant cases where maintaining the safety of the community requires rapid action. There's a lot of thought put into antiharassment efforts that argues for fairly rapid resolution of issues rather than the long drawn-out processes that Daniel supports. You can be constructive and disagree with all that. There are really big questions of fairness and no good answers. However, constructively participating in a discussion involves learning enough of the history and enough of the positions (especially those of people you disagree with) that you can treat those positions with respect. You should be able to respond to their points and demonstrate empathy for the needs of others in the conversation. Daniel didn't do that, so I don't think he's being constructive here. Wheter it is actually sealioning or simply ignorance of other positions, the result is the same: he asks us to be drawn into a huge, painful, drawn-out discussion where we take on the duty of educating him and any trolls that are attracted by his impassioned language. I personally choose not to take on that burden here. That said, Daniel brought up one point I would like to discuss with anyone who would be interested in bringing about changes. He points out that we have events where we have face-to-face time and we could use them more effectively for working through disputes. I'm not interested in debating with Daniel about whether the process should require that. I am very eager to discuss how we can do more of that empathy building and dispute resolution at events. --Sam signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2019: Call for nominations
We seem to have reached the end of the nominations period with no Debian developers stepping forward to nominate themselves. As has been discussed, the nomination in is not valid because the person nominating themselves is not a developer. In fairness, I'd recommend that the nominations period be extended for some explicit time. I think that we want to have a known window for new nominations rather than say starting the campaigning as soon as someone nominates themselves.
Re: Binary compatibility policy for security updates and point releases
> "Jakob" == Jakob Leben writes: Jakob>Well, there are use cases that are not so simple. For Jakob> example: I might deploy Debian 9.1 on an embedded machine Jakob> sold to a client on the other side of the world. I have a Jakob> system for updating my own software which is also deployed on Jakob> that machine, but not the rest of the Debian system. Now, if Jakob> ABI might change between 9.2, then I have no guarantee that Jakob> if I test my software update with 9.2, it will be work as Jakob> expected on the client's machine with Debian 9.1. However, Jakob> building and testing my software with Debian 9.1 might be a Jakob> problem. For example, the official Debian Docker images Jakob> (https://hub.docker.com/_/debian) are only provided for the Jakob> latest point release. Finding older point releases from other Jakob> sources is also not the simplest, and seems to be discouraged Jakob> and not perfectly supported. See for example the notes here: Jakob> https://cdimage.debian.org/mirror/cdimage/archive/ Note that Jakob> this use case requires that ABI does not change at all - not Jakob> even in a backwards compatible way, because in that case I Jakob> might inadvertently start using a new symbol introduced in a Jakob> library in 9.2 which is not present on the client's 9.1 Jakob> system. For these reasons, I would appreciate if the Jakob> documentation was a little more transparent about binary Jakob> (in)compatibilities across point releases and security Jakob> updates. I think the best you're going to get is that we're aware of the issue and that we try and make ABIs backward compatible (although not frozen) between point releases. Some other factors like minimizing changes overall between point releases tend to make ABIs fairly stable (no new symbols), but I'm aware of cases where new symbols have been introduced to fix important bugs or security issues. However, there are cases where we've broken ABI compatibility within a stable release. Haskell is one of the more obvious cases: simply rebuilding a dependency can break the ABI of a Haskell library. If you distribute your software as Debian packages, then you can express your requirements as dependencies and at least know whether the customer has a new enough point release (and even handle knowing whether you have the right Haskell dependencies). If not, in practice things will work fairly well, but you are correct that there are corner cases that can be problematic. We certainly are awary of the issue, but it is something that needs to be balanced against other tradeoffs. --Sam
Re: metaphors and feminism
I always assumed debian member was a term that included developer and maintainer. I'm all for Debian member replacing developer, but if so, I'd like a term that encompasses maintainer and developer.
Resignation from the Antiharassment Team
Effective immediately, I resign from the Antiharassment team in order to take on the role of Debian Project Leader. I think that there are a couple of conflicts that make holding both roles problematic. The biggest is time management. However, while the DPL and AH both have roles in dispute resolution (and even dealing with the code of conduct), I think the focus is somewhat different and I'd find it easier to know what my focus needs to be. There's also a conflict because the AH team is exploring the idea of a formal delegation and I'd rather focus on that from the standpoint of evaluating whether the team is ready and whether we as a project have a good understanding of their role. This is a bit awkward since there has been no announcement that I ever joined AH. I was accepted as an apprentice member and was undergoing training. I have never been on the antiharassm...@debian.org alias, although I have talked about some hand-picked issues. signature.asc Description: PGP signature
RFA: rtc.debian.org
Hi. During a discussion with DSA, we noticed that rtc.debian.org does not have an active service team maintaining it. In addition, the reciprocate package, on which it depends, was dropped from buster. I think the RC bugs in question have since been fixed but I didn't go look at all the dependencies. The default option is to discontinue the service. First, it would be useful to hear from active users of the service. At one level, even if the service is actively used, it won't be continued without maintainers. However, understanding who would be hurt by this would be valuable. Secondly, if you would be willing to step up and maintain the service please follow up. You'd also need to be willing to maintain the packages involved in coordination with the voip team. Thanks, --Sam signature.asc Description: PGP signature
Re: Than you!
Your thanks are most welcome. Sam Hartman Debian Project Leader
the #debian-ddpl IRC channel on OFTC
Hi folks. Some DPLs in the past have used the #debian-dpl channel on OFTC. Chris didn't. I'm trying to figure out whether I am going to use the channel, but for now I'm hanging out there. If you hang out there, I'm assuming you're willing to assist the DPL on the channel trying to understand things. So, asking questions about how reimbursements and treasury works, asking who I talk to for X, that sort of thing. Asking for sanity checking of email before I send it, etc. It's import to be careful about using it as a place to make decisions. It's not archived, it's not any sort of formal forum. I feel comfortable seeking input there when I'd like some input but when there is no formal requirement that I seek input. Much the same way I might feel comfortable talking to a developer I trusted and seeking their input. However, for decisions where there is a requirement of transparency or community consensus, #debian-dpl is entirely the wrong forum. my mind is still open on whether I will end up using the channel long-term. However, since I'm still there after a few days I decided to send a note to -project letting people know that #debian-dpl is a place where some discussions are happening. signature.asc Description: PGP signature
Re: the #debian-ddpl IRC channel on OFTC
A recent conversation on IRC caused me to realize I should have pointed out a couple of things. These are obvious to me but may not be obvious to others. IRC is not email. I may ignore IRC when busy. I do not have a permanent IRC presence. I may lose messages in various ways, and my IRC client doesn't track which messages I've responded to. If you happen to get a response from me on IRC (including #debian-dpl) that's great. If you don't get a response and you wish you did, send email. IRC and IM in general is not something I treat as a reliable communications channel.
Re: RFA: rtc.debian.org
Is the xmpp server part of rtc.debian.org or another service?
Re: RFA: rtc.debian.org
Hi. If I'm understanding you correctly, what you're saying is that you believe this project is more than one person can handle and you're giving two examples: 1) You don't know how to interact with DSA and 2) you don't understand the current setup. I suspect you're right that this is more than one person can handle. If that is what you're saying, then thanks for volunteering and for being honest. But you might be saying that if you had more experience working with DSA and understood the current setup, then you could handle it. If that's what you're saying I could try to get you help on those two points. My recommendation is that it's more than one person should take on, but I want to make sure that I'm not misreading a request for specific help. --Sam
Question for Planet Admins: What Should I do if another Developer Removes my Blog
Speaking as an individual, although some of the things that motivated me to actually go ahead and ask this question knowing that it might spark discussion were conversations I had as DPL. Obviously this question is motivated by things that happened last year, but I'm not asking about that situation, and the details of the question I'm asking are intentionally different in ways that matter at least to me. I am asking this question because in multiple conversations with members of our community related situations have come up and I'd like to better understand how we think we should approach disagreement in use of a shared resource. Imagine that I get a note from a random developer saying they have removed my blog from planet. I understand what they are saying enough to believe it is not vandalism; they honestly believe I did something wrong. I can't understand from their message how they hope I'd fix it. I cannot engage with them in what I think is a timely manner. They copied the planet admins who have not gotten involved in the conversation. What should I do? 1) Add the blog back myself, asking the person to appeal to the planet admins if they still think my blog should not be present? 2) Ask the planet admins to respond to the situation and either help me understand the problem or add my blog back. In my mind the question pops up because we have two conflicting things. It's not really clear that random developers should be removing blogs from planet. On the other hand planet is a shared service and if there really is a critical issue, it's better to get it fixed. However, revert wars are antisocial in and of themselves. --Sam signature.asc Description: PGP signature
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Question for Planet Admins: What Should I
Ian> do if another Developer Removes my Blog"):
>> Imagine that I get a note from a random developer saying they
>> have removed my blog from planet. I understand what they are
>> saying enough to believe it is not vandalism; they honestly
>> believe I did something wrong. I can't understand from their
>> message how they hope I'd fix it.
>>
>> I cannot engage with them in what I think is a timely manner.
>>
>> They copied the planet admins who have not gotten involved in the
>> conversation.
>>
>> What should I do?
Ian> Does the answer to this question depend very much on whether
Ian> it's Planet that's the territory for the revert war ?
Ian> ISTM that the same can be true of bugs.d.o at the very least,
Ian> and salsa, and, in principle, even the archive.
That's why I'm asking the planet admins. I'd argue that in general we
delegate responsibility to people to run services as they choose.
It's more complex than that of course, but it's certainly common for us
to give people wide latitude to do their jobs.
So planet admins might well take a different approach than owner@bts or
salsa or...
And absent some project-wide policy or an override or something I think
the planet admins do get to decide for planet.
I think the general question is interesting, and a very reasonable
answer from the planet admins might be "We haven't thought this one
through, let's have a general discussion."
If people do decide to have the general discussion I'd appreciate it if
they were to change the subject.
--Sam
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
> "Jonathan" == Jonathan Carter writes: >> 2) Ask the planet admins to respond to the situation and either >> help me understand the problem or add my blog back. Jonathan> Option number two seems like the entirely logical and Jonathan> reasonable approach. If it seems that you've overstepped Jonathan> it doesn't seem like a good idea to antagonize the admins Jonathan> any further, so I don't think that just adding the blog Jonathan> back without any further feedback is every a good idea. What antagonizes the planet admins is kind of at the crux of this question now isn't it? And the answer to that depends on their needs and goals. I'll say that if I were a planet admin, like you, I'd prefer option two. But multiple people with different outlooks from each other have been talking to me about this. And to them, option 1 was so obviously right in our community that they didn't even consider that there might be another answer. And I found myself having arguments about what the planet admins surely must think. I decided that since I can go actually talk to the planet admins and find out, that might be educational on a number of fronts. --Sam
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
> "Benj" == Benj Mako Hill writes: Benj> I'd be happy to document this on the Planet wiki page. I agree with Joerg that I don't think we need a lot of new rules here. I'll point out that the situation I asked about has never happened (although one close to it in some ways did), and it feels premature to go set policy based on a hypothetical. My take away is that there are complexities in situations like this. Sometimes when you have technical access to do something but it's unclear when you should use that technical access, acting may be the right thing to do. When that happens talking a lot is often a really good next step. Escalating the situation is something I'd personally recommend against. --Sam
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
> "Norbert" == Norbert Preining writes: Norbert> On Tue, 21 May 2019, Scott Kitterman wrote: >> I think it's more open and equally clean for someone who's blog >> has been non- consensually removed to be able to put it back >> themselves immediately (if they think the removal was >> unreasonable) and point the remover at the Planet Debian admins. Norbert> Agreed. If this is not the case, what would come next? Norbert> Arbitrary take over of package maintainership because we Norbert> are unhappy with how X maintains their packages. First, removing something from planet is much more akin to an NMU than a maintainer change. And NMUs do happen all the time. And there are procedures and policies, and they are often followed. When they are not, sometimes it's hardly even remarked because the solution was so obviously the right thing. And sometimes it sparks significant discussion. The same is true of package maintainership though. We sometimes do change the maintainership because we're unhappy with how someone maintains their packages. That rarely uses the formal policy that goes before the TC who have the constitutional power to decide who maintains a package. Sometimes when a package maintainer is changed the response is hardly a squeak: it was generally regarded as the right thing. Sometimes it sparks a lot of discussion. And how people use the technical powers they have gets factored into our continuing estimate of trust of those people. As a matter of technical capability we can all do a bunch of arbitrary things. As a matter of practice we sometimes do things that according to written policies and procedures seem kind of arbitrary. And if anyone has a problem with it, we discuss and work towards either agreement that the arbitrary thing isn't something we want or an understanding of why it is something we want. It's frustrating if you want hard and fast written rules. But it works a lot better than if we did try to write down those rules. --Sam
Re: RFA: rtc.debian.org
> "Jonas" == Jonas Smedegaard writes: Jonas> I also run Asterisk at a few small networks, and experienced Jonas> similar failure connecting with rtc.d.o in the past - but I Jonas> didn't try very hard back then. Jonas> I sincerely hope these renewed efforts can help improve the Jonas> experience. Jonas> No doubt helps also that the protocols and implementations Jonas> have since matured some. I played around with asterisk and rtc in browsers. The issue I ran into was that libpjsip had several compile-time constants that produced buffers too small for some of the SIP messages that webrtc uses. When you're using audio, video, DTLS, and ICE, your sip messages kind of get big. I never tried with rtc.debian.org but I did get things working with chrome, firefox and asterisk. Unfortunately, I think that increasing the compile-time constants may break the pjsip API, which may be why Debian doesn't do it. (It may have sense been done; this was a while ago) Honestly I think an organized ABI breakage would be worth support for webrtc that works with real browsers in asterisk. If I weren't being DPL at the moment, I totally would have volunteered for this myself. I'd certainly be open to being roped into a couple hours helping at debcamp or something.
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
> "Mathias" == Mathias Behrle writes: Mathias> * Karsten Merker: " Re: Question for Planet Admins: What Mathias> Should I do if another Developer Removes my Blog" (Sat, 25 Mathias> May 2019 17:49:13 +0200): Mathias> Hi together, Mathias> I am supporting wholeheartedly the view of Carsten with Mathias> some small amendments. In this whole discussion I've been speaking as an individual developer. I find your position and that of Carsten confusing. At one level you're arguing that we're not planet admins and should not do planet admin things. But then you spend the rest of the message saying how planet should be run...you spend the rest of the message actually trying to assert the sorts of things that you said ought to be left up to the planet admins. And the planet admins have already spoken on this issue and they don't agree with you. Joerg's message made it clear that the situation is more nuanced than Carsten's approach, and Mako went even further than Joerg. I'm confused when you respond after the planet admins do without taking their points into account. I've certainly confirmed my original suspicion that our community has a wide set of views on this issue. --Sam
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
>>>>> "Norbert" == Norbert Preining writes: Norbert> Hi Sam, surprising statements from you ... Norbert> On Wed, 22 May 2019, Sam Hartman wrote: >> The same is true of package maintainership though. We sometimes >> do change the maintainership because we're unhappy with how >> someone maintains their packages. That rarely uses the formal >> policy that goes Norbert> ??? This seems to be new - at least when I became DD some Norbert> 10+ years ago this was not the case, and it was completely Norbert> out of discussion to do this. I'm reasonably sure there are situations over the years where we as a community have concluded that a package highjack was acceptable. I might be wrong. I'm quite confident there are cases where someone has started NMUing a package because a maintainer is inactive and has eventually declared themselves the maintainer without following the letter of documented practice. Norbert> Why would we need "package salvaging" (thanks Paul for Norbert> that!) Norbert> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging Norbert> if we can change package maintainership just like that? Because "just like that" involves a lot of careful thought, sometimes a flamewar, and sometimes long discussions of whether something is the right answer. When we've done something enough that it's worth writing down a right answer ahead of time to shortcircuit discussions, we sometimes do. Package salvaging is in my mind one of those cases. Norbert> I will remember your statement the next time I consider Norbert> another maintainers packaging efforts insufficient. OK. but let's make sure you understand what I'm saying fully. I'm saying that as a DD you have the technical capability to change the maintainership of any package. If you do that outside of the written procedures you should be prepared to defend your actions and suffer consequences if the community disagrees with you. Imagine that you write to d-devel, propose some action and get a fair bit of support. But you didn't quite wait long enough or the maintainer pops up just as you do the upload or something. It's likely the only consequence will be that we might conclude as a community the best option is to revert your action. If you don't ask for input and go off wildly on your own it's likely the consequences will be significant. My point is that as a community we don't typically jump at "you broke this rule, bad!" We typically also think about whether enough good was served to justify breaking the rule and whether you might have found a case where the rule was poorly crafted. >> As a matter of technical capability we can all do a bunch of >> arbitrary things. As a matter of practice we sometimes do things >> that according to written policies and procedures seem kind of >> arbitrary. And if Norbert> I am not sure what you mean with *we*, but I am sure that Norbert> most "normal" DD are not allowed to overstep the rules that Norbert> easily. I don't think it is easy at all. Going and doing something and then waiting to see whether the community agrees with you that unusual action is justified doesn't seem easy to me. My point is that the planet admins are taking a position that seems fairly consistent to me with the same position we take for package maintainership. Normally, you follow the written rules. Sometimes there are exceptions. If you act on what you believe is one of the exceptions, then the community's trust in your actions will be re-evaluated based on whether the community agrees with what you did. --Sam
Realizing Good Ideas with Debian Money
[moving a discussion from -devel to -project where it belongs] > "Mo" == Mo Zhou writes: Mo> Hi, Mo> On 2019-05-29 08:38, Raphael Hertzog wrote: >> Use the $300,000 on our bank accounts? So, there were two $300k donations in the last year. One of these was earmarked for a DSA equipment upgrade. DSA has a couple of options to pursue, but it's possible they may actually spend $400k on an equipment refresh. $200k doesn't really go that far in terms of big infrastructure projects like bikeshed or similar. I'm looking for someone who would be willing to guide a discussion of the Money issues Martin brought up in his campaign. I don't have time to guide that effor myself. Real thought needs to be put into it; it will be at least as much work as the discussions I'm leading on packaging practices and git if done correctly. However it could be very valuable for the project. --Sam
Re: paying people for Debian work (Re: Why do we take so long to realise good ideas
> "Holger" == Holger Levsen writes: Moving this subthread to -project too. Holger> But there's one significant difference between LTS and dunc Holger> tank: dunc tank was ment as an initiative inside Debian, Holger> while LTS is carefully set up on both sides, in- and outside Holger> Debian, and the money part of it is *completly* handled Holger> outside Debian, and I very much like this and I consider Holger> this a main reason why LTS is accepted by the Debian Holger> community. Is it true that dunc tank was an initiative inside Debian? When I go back and read Joerg's mail to debian-devel-announce summarizing the concerns with Dunc Tank, it sounds like it was outside Debian possibly sharing some of the same people running it. I was a member at that time, but honestly wasn't paying much attention to that aspect of the project.
Re: Realizing Good Ideas with Debian Money
> "Adrian" == Adrian Bunk writes: I agree that's missing. I don't think that is the important information needed to drive the discussions I'm hoping someone will drive. Instead I'm more interested in seeing discussions at a high level. Talking about the issues involved in paying people to do work. What the options are, collecting people's concerns etc. I actually think the first round of that can be done without significant access to numbers. That said, I'd sure like that anual report (actually I'd love it quarterly) you speak of above. I'm not volunteering. Are you? --Sam
Re: Realizing Good Ideas with Debian Money
> "Ondřej" == Ondřej Surý writes: Ondřej>It might be worth looking on how other organizations in Ondřej> our ballpark are doing stuff. f.e. IETF/ISOC is in similar Ondřej> situation to Debian/SPI. I'm no longer really involved in the IETF, but I was involved in the IETF for a number of years and was involved in a leadership role when the previous structure was set up. (They are going through a transition to replace the IASA with the IETF LLC right now, and I don't even understand why they think that's a good idea; haven't even read the RFCs involved) ISOC was careful not to fund any standards work. So under that model mapped to us, DPL, RT, all the decisions of ftpmaster, TC, NM, DAM, debian-legal, Debconf content team, and all the packaging effort would be unfunded. There was an administrative director who worked on contracts, RFPs, and who managed relationships. Then a lot of tasks were contracted. There were some fairly long-term contracts for rfc-editor and for the secretariat (who did debconf local/global team stuff, who ran the non-RFC parts of the archive (id repository) (other than content decisions), and helped with administration for bi-weekly document calls etc). Then there were contracts for things like tools development. So things like DSA, dak development, development of release team scripts would be contracted out for big projects. Smaller things and ongoing maintenance would be handled by volunteers. Deciding what was wanted, writing requirements specs, etc, etc would be done by volunteers. With regard to Russ's concerns, I think that making short-term grants to work on specific projects might be much more achievable for us than salaries. It reduces the factors he's worried about. I think there would still be significant risk, but not nearly as much as if we were actually paying salaries on an ongoing basis. Factoring in past performance would be easier for new grants than trying to fire someone. But I think even given that the concerns would be very real. That said, even in the IETF community there is very much an in croud for the administrative stuff. The same people seem to often be getting the contracts. If you actually cared about the business it seems like it would be very easy to get feelings hurt. Also, basically all the tasks the IETF pays for are very far from the actual work of the IETF. I actually think that Debian could possibly hire people to do our website on a contract without it being a huge problem. We'd explicitly want the www team (or hopefully no one in our community) not to bid. We'd want the www team to be guiding the process and for the contract to be about doing the things they don't want to or never get around to doing. We'd want it to be something we'd be willing to do again in similar circumstances, so that if it did actually change what people were willing to work on that would be OK. In that model, the www team would be more about deciding overall structure, making the decisions than actually going and implementing them. But for a lot of what we do, it's close enough to our core that the mix of money and power would be problematic. As an example, even having people work on the dak software seems like it would run into trouble as they could influence which features got implemented etc. When you start funding positions that actually have power to make project-level decisions, I think you run into a lot of challenges. --Sam
Re: Realizing Good Ideas with Debian Money
> "Adrian" == Adrian Bunk writes: >> >> Talking about the issues involved in paying people to do work. >> What the options are, collecting people's concerns etc. >> >> I actually think the first round of that can be done without >> significant access to numbers. >> >> That said, I'd sure like that anual report (actually I'd love it >> quarterly) you speak of above. I'm not volunteering. Are you? Adrian> My biggest high level concern is the income side, since this Adrian> is the most difficult part and will likely also be the most Adrian> controversial one. Ah, I was actually asking if you wanted to volunteer to work on the reports since you seemed to value them. I was only one quarter serious: if you did want to do that work, I'd be thrilled, but I didn't really expect it. I think it's actually impossible for a non-profit to reduce income from expenses. It's a lot easier to do fund raising when you can explain why you want the money. I think it's no accident that when people learned our sysadmin team no longer had hardware donors and was considering how expensive continuing their current strategy was, we got two very large donations, one of them intended to make that possible. Yeah, unless you want debt (which we almost certainly do not), income needs to lead expenses. But when people see you spending their money for purposes they believe in, it's easier for them to give you more. When they understand your needs they give more. I don't donate to Debian. (I do sort of donate to SPI, but I'm considering stopping). In both cases I value the organizations a lot, but I don't actually think they need my money. Both organizations seem to have funds adequate to meet their own expenses. So why should I give them my money? --Sam
Re: Realizing Good Ideas with Debian Money
> "Gunnar" == Gunnar Wolf writes: Gunnar> I am aware your example is just an example - But don't you Gunnar> think that following through with this would have a sad Gunnar> effect on the www team: It would be equivalent to tell them, Gunnar> "thanks for your work for so many years, but we have decided Gunnar> it's a weak spot in the project, and we'd be much better off Gunnar> if somebody else were to do it". If that were there reaction we shouldn't do it. I was imagining that if we went to www, treasurer, or a couple of other teams and said things like "Hey, from your last couple of reports you don't seem to be able to get all the things done you want to dget done. We don't seem to get you volunteers, but would you find it useful to have some money to contract for some of those items? Because this is new, we'll help you out if you don't have experience managing a contract well." I'd be really surprised if their reaction was to feel their work was not valued if presented like that. And if so, we apologize and move on.
[respond by Jun 20]: Call for Feedback on the Antiharassment team
Dear Debian: I'm seeking feedback on your interactions with the antiharassment team. Ultimately I'd like to learn how well they are meeting the needs of the project in helping to keep our community welcoming and safe. As discussed in my bits from the DPL, A group of us is meeting in late June and I'd appreciate comments by June 20. Comments received between June 20 and the start of Debconf in mid July will still be useful, but not as valuable as comments received by June 20. I'd appreciate it if people would help spread the word and let people know about this request for feedback. Your specific comments will be kept confidential (although if you mail lea...@debian.org as requested, future DPLs will be able to read your comments.; hartm...@debian.org goes only to me) However I will summarize and consolidate feedback and share both with the antiharassment team and potentially with a broader audience like debian-private or debian-project. I'm interested both in feedback from people who approached the antiharassment team and in feedback from people approached by the antiharassment team or its members. Please let me know generally when the contact happened, because the team and its procedures have changed over the years. I'd like to hear what went well. What went poorly. Were you a reporter, respondent or both? Did the turn around time and frequency of contact meet your needs? Did you feel respected during the process? Did you feel that your input was considered? Were issues resolved to your satisfaction? Did you feel that your interaction with the team helped keep Debian welcoming and respectful? If so, what contributed to that? If not, what could have been done better? Thanks for your consideration and any input you'd like to share. signature.asc Description: PGP signature
Re: RFC: endorse debian-mentors as entrance to our infrastructure projects
Paul, it's really cool to see that you are open to this. I wonder whether it might be a good idea to write down which infrastructure services people in the mentors community are most able to help with. I don't want to discourage people from for example asking dak questions, but it might be valuable to indicate that for example we have better coverage of LDAP than dak (assuming that's true). I find setting expectations helps avoid frustration. --Sam
Alternatives to the Socratic Method
> "Chris" == Chris Lamb writes: Chris> Personally, I have been over-indulgent in using such "devil's Chris> advocate" positions in the past, but after some feedback I Chris> realised that it did not have the intellectually stimulating Chris> quality I was hoping for and merely distanced myself from Chris> whom I wished to convince. After reducing my usage and Chris> spending moretime & effort adopting alternative modes of Chris> argument I found my attempts to connect with and ultimately Chris> persuade others to be far more effective. I'd be really interested in the alternatives you're found helpful twhen what you really have are a lot of questions. When I find I have a strong emotional reaction to something I like to try and step back and honestly learn about it. For me that generally involves a lot of questions. But even through email I find that it is sometimes obvious while I'm asking those questions that there are strong emotions under the surface. Often by the time I get answers, the emotions are gone, and I approach the answers and then develop a reasoned position. So I'd love to learn what has worked for you when you do find that you have a lot of questions about something. --Sam
Accessibility of Ledger Reports
Hi. An issue came up processing a debconf budget amendment. Our community uses ledger a lot for dealing with financial issues. Unfortunately, I find that its reports are not very accessible at least by default. The issue I'm most running into is that the reports use internal indentation within a line. That is, to draw an account tree ledger indents the column containing the account name depending on its level in the tree. Certainly for the screen readers I use, and I think for most of the ones in Debian, that's hard to approach. I found that I can view the file in Emacs with whitespace mode enabled, and that's my best bet so far. i'm also told that there is a --flat option that displays the entire account tree. I suspect that's really annoying for others. Indentation in the first column of a line is very easy to deal with for any screen reader that a Python programmer would use. I'm hoping we can brainstorm somethinfg that works reasonably well for me and for the rest of the community, so I'm bringing up the issue here.
Re: Accessibility of Ledger Reports
> "Louis-Philippe" == Louis-Philippe Véronneau writes: Louis-Philippe> Is that more accessible? From what I understand from Louis-Philippe> your email, the beginning indentation isn't a Louis-Philippe> problem. If it is, we can script something to get Louis-Philippe> rid of it too. Yeah, --flat is definitely easier for me. Is there any way to have the account name as the first column? That would probably also work well.
Re: Accessibility of Ledger Reports
>>>>> "Sune" == Sune Vuorela writes:
Sune> On 2019-06-10, Sam Hartman wrote:
>> Unfortunately, I find that its reports are not very accessible at
>> least by default. The issue I'm most running into is that the
>> reports use internal indentation within a line. That is, to draw
>> an account tree ledger indents the column containing the account
>> name depending on its level in the tree.
Sune> Would a GUI with a file manager like tree interface help in
Sune> any way?
Well, in general, people are trying to share these reports in email, so
I'm not quite sure how that would work.
But yes, GUIs or web UIs do work fairly well for this. As an example the
odoo web apps analytic chart of accounts and chart of accounts work
similar to what you're talking about and work fairly well from an
accessibility standpoint.
Similarly their analytic balance sheet and balance sheet are layed out
in a manner that is reasonably easy to follow.
Re: Realizing Good Ideas with Debian Money
Hi. I've received a media query on this topic I am about to respond to. I figure the project would not take it well to find out what we're going to do from a news story. And obviously I don't know what we're going to do, but I do think I know where we ended up here and what I'd be open to helping with as DPL. There is insufficient support at this time to entertain paying salaried positions from Debian money. Some of the objections include the following. We don't have sufficient recurring funds. Managing people and handling performance issues is a skill set we do not select for. Doing that could create significant power imbalances. If we're going to start somewhere we'll start smaller. I think there are significant challenges and concerns paying for core functions related to our operating system from Debian money. It creates complex and potentially concerning feedback loops in terms of prioritization. Today, if you have (or pay for) the time, you gain significant influence. That has its own problems, but changing that would give power structures within Debian control over what Debian is in some strange and hard to understand ways. That makes a lot of us uncomfortable. So I don't see supporting using Debian money to pay the DPL, TC, packaging, release team, security, archive functions of ftpmaster or the like. However, encouraging others to pay Debian developers for Debian work seems to have general support. There are some concerns about how LTS is working, but overall we seem relatively happy. Expanding that model to help connect money with qualified Debian community members seems worth pursuing. Similarly, I'd be open to the idea of pursuing grants or contracts to fund projects not related directly to our operating system. There are a lot of things we do that everyone has to do: run IT infrastructure, keep our accounts, run a website, run conferences. Many of those we do our own special way. That's great, and so long as we have volunteers to do the work and those volunteers are happy and have the resources we need, we should keep right on being excellent. However, if our volunteers need help and contracting for effort to help them would make Debian better, we can consider that. Similarly, if we cannot find volunteers to do work but we could find volunteers too coordinate, then contracting may help. In areas not related directly to our operating system I'd be open to experimenting with using Debian money. As I've said, I won't drive that effort: it's simply not my focus as DPL. I'm happy to working with the right person to put together a proposal to experiment with a couple of grants. If you're interested and have the time to drive such an effort, approach me at Debconf or write to me after Debconf settles. I currently expect that I'd want to take such an experiment to a project wide vote before allocating funds. --Sam signature.asc Description: PGP signature
Re: Realizing Good Ideas with Debian Money
It was pointed out to me that my mail could have been misread in a number of ways. nothing in my message is meant to alter the delegations currently in place. Rather, my desire is to further empower our delegated teams. If there are going to be any grants to fund work for some of our teams, the teams need to eagerly support the idea and have appropriate involvement in the process. The obvious and simplest way is for the team wanting to issue a grant to be the one running the experiment. There are other options that may make sense. For example if someone who had experience with grants or contracting wanted to put together the experiment that could be fine. But it would need to be as a resource for the teams that the teams saw as such, not antagonistic to our great volunteers. --Sam signature.asc Description: PGP signature
Re: Debian supports pridemonth?
Hi. Responding only to one thing at this time, and apologies if it has already been covered. This was discussed by the debian publicity team who is delegated to do this sort of thing. In particular, they are charged by the project and DPL to promote Debian consistent with its policies and their choices. Like most of our teams they have significant latitude. In this instance, they are guided by the constitution which encourages delegates to respect project consensus/policies/positions. So, they are guided by the GR approving the diversity statement. This action was discussed on their public list.
Re: Debian supports pridemonth?
> "Roberto" == Roberto C Sánchez writes: Roberto> It does not seem that anything was done with the intent to Roberto> conceal the action, nor do I mean to imply such. However, Roberto> the start of the thread was practically invisible Roberto> (especially for someone monitoring many Debian-related Roberto> mailing lists). I would be surprised if more than a very Roberto> small handful people even knew such a change was in the Roberto> works. The interesting question is whether those active in the publicity team were aware of the change. The whole point of delegation is to allow small groups of people to act quickly without reaching project consensus for everything. If we're hearing from active parts of the www or publicity team that this was inadequately discussed, that's one thing. The publicity team can seek broader project input when they need to, but has wide latitude within their area of responsibility.
Re: Debian supports pridemonth?
>> 3. what aspect of the political connotation of Pride Month you find >> objectionable, if any. >3. This is something I don't really think is on-topic on this list, or >in Debian at large. However, since you asked, I especially find Hi. I think your first inclination was right. I don't think it was appropriate for Branden to ask you your politics, and I agree with you that it's off topic for Debian. Thank you very much for being open and honest, but let's not discuss that particular sub thread any further. You shouldn't need to share your objections to pride month, and you should not have to face us critiquing them. It is in fact not really on topic.
Debian Videos
Speaking as an individual developer. One of my coworkers, Matt Tennie, will be attending his first Debconf this year. He has a lot of video production experience . He's been asking me questions about Debian, and somewhere along the way we realized it would be great to make available answers to common questions in a very accessible format. I think an example could illustrate. Matt asked me when gstreamer 0.16 would make its way into buster. "It won't," I said and moved on with whatever I was doing. The next day he came back and said he really wanted to understand better, because it didn't make any sense at all that we wouldn't want the latest software. So I started to explain about stability guarantees and stable releases. I talked about hand reviewing changes during the release. We looked at the reverse dependencies of gstreamer. I talked about how even in the best cases sometimes changes break a reverse dependency by accident. Then I talked about APIs and ABIs and started talking about the cost in terms of man power of actually pulling in a change. But to make a long story short, I gave the 10 minute version of why do we value stable releases, and what all is involved in that. Matt and I were talking about how it would be fun to capture things like this in videos and help users or new contributors understand what makes Debian. I think examples might include: * The stable release discussion we already had * When to use packaged software vs upstream software * Why is it so hard to make a package for Debian * Why it is involved to become a Debian developer (and how you can contribute with less effort if desired) * Debian vs crates/gems/eggs/CPAN/what have you I'm sure there are lots of these. If we did succeed in something like this I'm imagining releasing content both on a libre platform of some kind as well as youtube. Mostly I wanted to float the idea, get input. Also wondering if anyone would be interested in meeting to discuss this at Debconf. --Sam signature.asc Description: PGP signature
Speaking your Mind
> "Norbert" == Norbert Preining writes: Norbert> Hi Gerardo, >> On the other hand, nobody but me has spoken openly to say that it >> was a mistake to issue that statement. So I'm taking that as >> meaning that there is indeed a project-wide consensus that it was >> ok. Norbert> I am currently in a dangerous position to utter anything Norbert> that is not in line with the current main way of thinking. Hi. I'm going to reply to Norbert privately with advice specific to his situation, but I've heard a number of people recently say they are uncomfortable speaking their mind because they're concerned about repercussions presumably from antiharassment, account managers, DPL, or list masters or similar. Russ talked about the inherent censorship we exercise as adults. I absolutely hope that we do watch what we say because we care about each other and we want to make sure we are well understood and do not hurt each other needlessly. I absolutely do hope we double check potentially touchy emails. I absolutely do hope that when we need it we ask others to read over what we send. But I don't want there to be a chilling effect out of fear. And I certainly don't want there to be a chilling effect caused by lack of understanding in how AH/DAM/DPL/listmaster work. I'm going to give some advice here, but please, if you are afraid to speak your mind, reach out on list, in mail to me, or in mail to antiharassment and let's chat. Our goal is to create a community that works together not a community of fear. In almost all the cases I'm aware of, problems come up based on how someone reacts when a member of our community wants to engage with them about their behavior. That's right, the problem is almost always how people are reacting to criticism, not their ideas or ideology. The Antiharassment team, account manager and I want to create a community where when someone approaches you with a problem, you're expected to engage with them constructively. When that happens, it is unlikely that action will be taken, and exceedingly unlikely that action will be taken quickly. Example of what we hope happens: * I say something * Someone says that they think I was disrespectful or hurt someone or similar. * I work to try and understand the concern and what the person bringing up the concern hopes I'll do differently. I create an interaction where they feel comfortable bringing up concerns with me in the future *especially* when I don't resolve the concern the way they were hoping I would. * I work to disagree with ideas not people. Especially if I'm coming across as judging someone for who they are or what they believe, I make my position more clear. * Sometimes we're going to hurt each other. Example: as DPL, when I contemplate changing delegations or team membership in order to improve a team, it's very likely that if people affected don't agree with my decision they are going to be very hurt. Treating them with respect in that situation can involve acknowledging the hurt, and trying very hard not to judge them as people. Demonstrating that you care when the things you say are painful goes a really long way. * Being responsive and keeping the discussion going matters a lot. I acknowledge that those of us working on conduct issues have significant improvement to make in this regard. But again the biggest number one thing you can do is to create a constructive interaction where people are comfortable coming to you with problems. If you do that and keep the communication open, you're very unlikely to be surprised by your interactions with Antiharassment, me or the account managers. Examples of Things that are Problematic: * When your response to a concern is to immediately deny that there's an issue. Sometimes you'll disagree, but please take the time to understand first. * Focusing on legalisms--did you technically violate some rule or not--rather than expressing empathy for what's going on. If someone is hurt when they read your mails or interact with you, please take the time to actually think about whether you can accomplish your goals without causing as much pain. If there are simple changes you can make that work for you and make things work better for them, does it actually matter whether you've violated the letter of some rule? * Attack the people bringing concerns or use a tone where they feel uncomfortable talking to you about issues they have. * Counter attacking/bringing up someone else's behavior without also working on the concern. "I'm not going to change until this other issue changes." * Be respectful especially in disagreement. Over and over again when talking to members of DAM, the message I've gotten for them is that the trigger for considering whether there is a membership issue is when someone is failing to constructively interact with the community. When they bully--when they respond so strong
Re: Debian supports pridemonth?
> "Adrian" == Adrian Bunk writes: >> and so forth, since they're the experts on what they would find >> the most meaningful within the Debian context. Adrian> Debian having a position on general political issues can be Adrian> dangerous. Absolutely. I think that each time we should link what we're doing back to our goal of making a great free software operating system for our users. And link back to our priorities of our users and free software. In this instance, the link is obvious for me. We as a community have decided that being inclusive helps us make a great free software operating system. Our diversity and publicity teams have decided that supporting pride month helps a part of our community feel more included. By helping this part of our community feel included we make it easier for them to participate. We let them know they matter. And I at least believe that makes it easier for them to contribute and thus we get a better operating system. I do think that linking any political action back to our goals and not letting our mission drift is important. I don't think we do that enough. It's just that in this instance I personally think the action is justified. Adrian> If Debian as a project is making general political Adrian> statements, then having a Debconf in Israel without a strong Adrian> public message regarding the situation of the Palestinian Adrian> people would make Debian appear to fully support the Israeli Adrian> side. I certainly think we should be making an extra effort to welcome Palestinian people to our project especially given the Debconf 20 decision. People are hurt by the Debconf 20 decision, and I think part of respecting them is to acknowledge pain that our decision has caused and to be as welcoming as we can. Adrian> Just like many LGBTQ project members might have a problem Adrian> with Debconf in a country where homosexuality is illegal. Yep, absolutely. Adrian> Most people from Israel are nice people and clearly welcome Adrian> in Debian, and so are contributors from countries where Adrian> homosexuality is illegal. Adrian> But if Debian does make political statements, then Debians Adrian> position on the Israeli-Palestine conflict is a valid issue Adrian> for discussions on project mailing lists and in GRs. I disagree with that. I do think that our position on how that conflict affects the Debconf venue selection is appropriate for project lists where debconf venue selection is on-topic. Adrian> The decision that Debconf 2020 will be in Israel can be Adrian> overridden by GR. Yes. There would be a high cost to doing that, but yes it can. Adrian> The easy way would be if Debian would consider itself a Adrian> purely technical project and abstain from making any Adrian> political statements, except ones strongly related to being Adrian> a Linux distribution. The easy and painful way. --Sam
Re: Debian supports pridemonth?
> "Eldon" == Eldon Koyle writes: Eldon> On Mon, Jul 1, 2019 at 12:49 PM Andrew M.A. Cater wrote: >> Eldon> >> Regardless of what some folk say about pridemonth - it is deeply, >> deeply, sadly, ironic and painful that folk are arguing about >> pridemeonth in mails interleaved even as a valued contributor >> announces she is trans. >> >> Tina - welcome to a life of having to defend your every move in >> every social and anti-social situation - but welcome regardless >> and with every good wish, as ever, >> >> Andy C. >> Eldon> It's unfair to conflate concerns about how the Debian project Eldon> observed pridemonth with some kind of ill-will for those who Eldon> celebrate (or are celebrated by?) it. Perhaps. But acknowledging pain we cause in our community is important. For those of us in the LGBTQ+ community, I think it is likely to hurt when we're trying to reaffirm that we're welcome in the project and that ends up being controversial. Remember we didn't just blanket support Pride Month. We talked about what that meant to Debian: https://bits.debian.org/2019/06/diversity-and-inclusion.html That blog post is about what joining Pride celebrations means to Debian. And it is directly and completely about inclusion. And yeah, when that ends of being controversial it hurts. And discussing and arguing about it is draining. And I'm sure that this is draining for people with different positions. And I hear people's worry and frustration when they are concerned that Debian is making political statements that they disagree with. So perhaps this discussion needs to happen. And sometimes we need to experience pain as a community. But I ask you not to deny that pain. Do not pretend that it's "just concerns," and that there is not a real cost to the discussion. Have it if you need to, but have compassion for everyone involved. And yeah, having your coming out within the Debian community and having it drop in the middle of this is damn well going to hurt. I'm not saying you're doing anything wrong by causing pain. But I am asking you to show compassion. --Sam signature.asc Description: PGP signature
Pride Month Discussion has Run its Course
[listmaster copied in hopes they will agree with my assessment here] The pride month discussion has gone beyond what's appropriate for debian-project at this point and has served its purpose. It's possible that small sub threads may have some value, but overall, I think that the discussion has moved into areas that are not productive. In particular, this morning's messages have basically verged into the territory of people asking basic frequently asked questions about diversity and inclusion, and various people stumbling through and trying to produce answers to these questions. If someone were asking poorly considered questions about packaging or software development on debian-devel, we'd eventually decided that debian-devel's job was not to educate someone in basic packaging/software development. Similarly, part of actually respecting the diversity statement in Debian means that rather than spamming the list with basic questions, it's our job as community members to go do some basic research and actually join the discussion when we have an informed opinion. The discussion of having an everyone matters month and collin's responsive mail explaining basic facts about privilege and sexual harassment were the last straws for me. If you are going to participate in a diversity discussion beyond a certain point you do need to actually spend some time with google just as you would for any technical topic. In this instance, researching arguments about privilege, criticism of the all lives matter movement, explanations behind the black lives matter movement (and why it is important to its members) would all be valuable. I'm not saying you need to agree with those things. I'm saying that when you are joining a discussion that has been going on for most of my lifetime, you need to do basic research. Just as if you popped up and suddenly knew that the solution to all Debian's problems was a rolling release, we'd expect you to go do some background reading. There are some links from the antiharassment wiki page to various resources, but I'll admit that the project doesn't have as good of a collection of background reading about diversity and inclusion as we should. I think trying to create that background info so we can stop badly rehashing long-running discussions would be valuable. And yes, we should (and I think do) have forums in Debian where people who have honest questions and confusion about diversity can get answers. debian-project is not that forum. --Sam
Re: Pride Month Discussion has Run its Course
>>>>> "Alexander" == Alexander Wirt writes: Alexander> On Tue, 02 Jul 2019, Sam Hartman wrote: >> >> >> >> [listmaster copied in hopes they will agree with my assessment >> here] Alexander> I don't agree, I think that discussion is important and Alexander> the tone is still civilized. The tone is absolutely civilized. And yet, the cost to people who have to do this education again and again is really high.
Re: Speaking your Mind
>>>>> "Holger" == Holger Levsen writes: Holger> On Mon, Jul 01, 2019 at 02:07:37PM -0400, Sam Hartman wrote: >> But I don't want there to be a chilling effect out of fear. Holger> yet today you asked this discussion to be stopped, even Holger> though the thread was civil and on-topic. I believe the discussion has drifted to a point where it is off topic. I explained why. It's my opinion that basic education about diversity and inclusion is off-topic fnor debian-project and that the discussion had diverged into this point. You can disagree with me, and apparently listmaster do, but we stop off-topic discussions all the time.
What can I do if I disagree with a Delegate's Decision
> "Roberto" == Roberto C Sánchez writes: Roberto> On Thu, Jul 04, 2019 at 10:18:18AM +0200, Raphael Hertzog wrote: >> On Wed, 03 Jul 2019, Roberto C. Sánchez wrote: Roberto> The point of Debian being a do-ocracy is not lost on me. Roberto> In fact, when it comes to technical matters, it is the Roberto> superior approach. Even in difficult technical matters Roberto> (like the init system debate) where the choices amount to Roberto> "do this" and "do nothing" there is a technical committee Roberto> which can act as arbiter. However, when it comes to Roberto> non-technical matters, esepcially when one potential course Roberto> of action is "do nothing," there is no such possibility. Roberto> Those who wish to "help" marginalized groups by displays Roberto> such as the pride month support have an avenue to "do" what Roberto> they believe is best in this do-ocracy of ours. What Roberto> course is available to me and those like me who believe we Roberto> should "do nothing"? It would seem that public discussions Roberto> that attempt to address that are met with great resistance Roberto> and with many attacks against the character, motivations, Roberto> and demographics of those who hold that position. Hi. So, first, if you want to have more influence in a given team, join that team and contribute active work to it. I don't think anyone here is saying that the teams in question shouldn't exist. So, even if you think the right option for a given issue is "do nothing," there are positive things you could do to gain credibility within the teams in question. Different teams have standards for how they evaluate concerns raised by members. But if all the concerns here were being raised by active members of the publicity team who contributed ongoing time, I'd expect the team to treat them seriously. If you are not willing to dedicate the time to a team, you have less influence, but there are still cases where project-level concerns matter. According to constitution section 8.3 delegates should attempt to follow consensus opinion. That means they have latitude to not follow consensus opinion in some cases, but I think it would be reasonable for us to carefully consider such situations. That is, I think it would be unusual for a delegated team to act when there is a project level consensus against their proposed action. I think it would be unusual for a delegated team not to adjust their future actions in response to a project consensus to do so. Of course, when we speak of consensus, we're almost always talking about some rough consensus model. You could rarely get a consensus of any kind with a full consensus (positive support, no one at all raising an objection they consider blocking) with the project as a whole. I think that because of the strong presumption that teams have significant latitude, you'd need a fairly strong project level consensus to counter that presumption. The discussion of supporting Pride Month has not reached a rough consensus that the publicity team should act differently under any rough consensus model we're likely to consider plausible. (The question of whether there is a consensus in this discussion in favor of their actions is more complex, but that is not the question that matters.) If you are unable to get a consensus, you have a few other options: * You can talk to the delegates about your concern.. You probably should have done this before the big consensus discussion anyway, but I'm too lazy to rearrange my message. * If the DPL becomes convinced that delegates decisions are too far out of sync with the project's needs, the DPL can adjust the members of the team. The DPL cannot overturn a specific decision, but alignment between project goals/needs and the goals/needs of the current delegate absolutely is something the DPL can consider when changing a delegation. In this instance, I support the publicity and diversity teams. * You can attempt to get sufficient support behind a project level policy. That could be done by consensus too, although if you failed to get sufficient support on a single issue, you might not have so much luck there. But you might have enough support to bring a proposed policy to vote in a GR. Delegates are not strictly bound by any such policy, but again, they *should* follow them. And it would be reasonable for the project and DPL to remove delegates who routinely ignored policy without adequate justification. A GR establishing non-technical policy only requires a majority to pass; that's not going to be enough to be a consensus, but in some ways votes are more binding. * And of course you can propose a GR trying to overrule the specific action or changing the delegation. I think those are your options in a situation like this. I hope that gives you a sense of empowerment. Even if you cannot get sufficient
Regrets Handling Conduct Concerns Earlier this Year
oject need to forgive ourselves, and I do think it is appropriate for me to start that work. [1]: https://www.nonviolentcommunication.com/freeresources/article_archive/emotional_healing_mrosenberg.htm So, having expressed my regrets and hopes, I’d like to remind us that there are reasons we did what we did. We might choose to act differently in the future, but we can offer compassion and understanding to ourselves. First, the people doing this work are all volunteers working to make the best Debian they can. We care about respect. We care about showing compassion when members of our community are hurting. We care about minimizing unnecessary pain and creating a welcoming community. This particular incident was challenging because it came at a point when people were very emotionally drained. And yet, some aspects of the situation required immediate action. Also, aspects of the situation had built up over years. Tensions were already near the breaking point. People did the best they could. Now we’re learning from the mistakes. As for the specifics. We were not the ones who dragged this onto a public list. But there are some positive consequences of that unfortunate situation. We learned a lot about what our project needs for transparency. We will have a better balance for how to share information with the members of the community while respecting privacy going forward. I hope we can develop better tools and success at bringing a conversation to a place where we can discuss how to help someone meet our standards. But it is really hard. Sometimes there are immediate problems you need to stop. People have strong responses when approached about a conduct issue. It takes a lot of skill and sometimes emotional energy to get past that initial response. We’re working to develop those skills and to understand appropriate limits for how we approach these skills. The Antiharassment job needs to be one that people can do without subjecting themselves to abuse. And the Antiharassment team has a significant communications challenge. A lot of people in that role have indicated that they are afraid to send antiharassment emails without a team consensus. Even once someone has indicated willingness to work on an issue, it’s difficult to be responsive enough for empathy and compassion while building a consensus behind communication. We still don’t have the answer for this one. The conflict of interest issue had no easy answer. There was one member of the AH team departing. There was one new member not fully up to speed. And there was a member who had some strong negative interactions with Norbert before joining the AH team. There was not a clear conflict of interest policy. Sometimes in situations like that you don’t have good options. So is this an apology? If you think that apologizing is about expressing regrets, understanding what you would do differently, and developing empathy for someone who is hurting, then absolutely this is an apology. We’re all going to have things we regret. Communication and respect are hard. I want a community where it’s easy to express these regrets. I want a community where we grow stronger and more confident every time we face our regrets and consider what (if anything) we would do differently. But if apologizing is about submission and humiliation and blame, then this is not an apology. Humiliation and denigration have no place in Debian. Sam Hartman Debian Project Leader signature.asc Description: PGP signature
Results of the Antiharassment Team Survey
[It feels like I've been writing a lot of these messages lately. I think this is the last thread I know I'll be starting on -project this week. It's likely I will be starting another thread on debian-private later in the week. And then off to Debconf!] Hi. During May and June I collected feedback about the Antiharassment Team from current and former members; from people who had interacted with the team; and from interested community members. I've attached a slide presentation that is slightly redacted from one I gave at the DA/AH/DPL meeting in June. I've also attached markdown sources that I ran through pandoc. I actually think that these results are consistent with what we've been seeing in discussions on debian-private and here. I think there's very broad support for the functions the antiharassment team is performing. There are a lot of people who expressed support for the Code of Conduct and for a team like AH. There are a few people concerned about potential problems we can run into in this work, but for example no one said that we shouldn't have a team working on conduct issues. Concerned individuals did raise issues of openness and avoiding chilling effects that they want us to be very careful of in this work. Unfortunately, there are serious concerns about our current implementation. It's my opinion as DPL that two of these stand out as critical issues that must be addressed. The first is that the AH team is not sufficiently responsive. The second is that we need to do better at actually engaging in mediation. By that I mean helping people understand what changes in behavior we're looking for and how to accomplish their goals within our standards. I do not mean the AH team should routinely engage in debates about whether particular conduct is consistent with our standards. My hope is that by addressing these concerns we can build stronger trust in the team. I don't think the survey alone would be sufficient to bring these concerns to the level of critical issues that must be addressed. Surveys like this tend to attract strong positive and negative feedback. However, we got a lot of feedback earlier this year on debian-project and debian-private. First, a number of participants brought up these same issues in those discussions. However, what I find more significant is the comments made by people who expressed support for the AH team. At least from a number of participants, this support clearly envisioned an AH team that was responsive and that effectively helped members of our community be effective in their communication while following our standards. I'd appreciate feedback on everything here, bum I'd especially appreciate feedback on whether I've correctly identified the right concerns to address. It would also help to know whether my analysis that these are critical issues is correct. Thanks for your consideration. I'd also like to thank everyone who gave feedback. I was amazed at how constructive the process was. --Sam Title: Antiharassment Feedbac (Public) Antiharassment Feedbac (Public) Sam Hartman June 22, 2019 Nature of Feedback Feedback from 17 sources Respondents; reporters;former and current team members; interested community members Very constructive Nature of Feedback (2) Methodology tends to collect extreme negative and positive feedback, tending a bit toward negative We probably also collect feedback from people who believe that earlier debian-private discussions do not validate their views Only community discussion will validate if my reading of feedback represents a consensus; if the feedback is too off the mark we’ll hear that when it is presented Bdale on CoC Sam’s summary of bdale’s observation: when the Social contract was adopted, everyone was basically in The CoC is a new requirement Several members do not consent When community values change without universal support, it will be hard. We may lose people. Ah Has a Fan Feedback from one respondent talking about how suggestions from AH have improved their communications and helped avoid frustration in the community Positive feedback about the bigger issues AH has tackled Debconf 17 Success Multiple people talked about AH’s success helping the Debconf 17 local team set up an incident level response team Feedback that this is important Ah Matters Significant feedback in support of the idea of an AH effort. One story described a particularly painful situation and talked about how if there had been an AH team back then, it would have been easier to handle. Except there was an AH team back then and the story even talked about how someone who (unbeknownst to the story teller) was an AH member was involved in trying to solve the situation. Ah Efforts Sound a lot like Oppression to Some Our approach to antiharassment is particularly uncomfortable to those who have lived under oppr
Re: git & Debian packaging sprint report
> "Andrej" == Andrej Shadura writes: Andrej> Hi, Andrej> On Wed, 10 Jul 2019 at 10:10, Sean Whitton wrote: >> Over the weekend, Ian Jackson and I met in Cambridge, U.K. to >> work on the design and implementation of tools and processes >> relating to git & Debian packaging. Andrej> Sean, are you coming to Curitiba? If yes, how about Andrej> organising a BoF on Git packaging workflows? He's not, but if you read the entire report you'd see a link to https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/ We'll be starting off early in the week trying to understand and catalog requirements, and I'm sure the fun won't end there!
Re: Results of the Antiharassment Team Survey
Hi. In this message I'm speaking as the DPL facilitating a discussion. I'm trying to explain where I see the project consensus (or in this case lack there of). That is I'm explaining what I'm hearing from the project and trying to focus future discussion. First, by this point, I have quite high confidence that my original reading of the project's requirements is accurate. Russ did not challenge my reading of what people had expressed; he questions whether that is a good idea. No one else has come forward to challenge that reading. Summaries like the ones I posted are very good at pulling forth disagreement: when people read such a summary and they don't feel like it reflects the discussion, they are very likely to reply. As an example, when Russ challenged mediation, he got multiple replies indicating that it was important. Moreover, I had a long phone call with Russ where we discussed various feedback we had receive. This issue is important to both of us; we've apparently both been spending a lot of time talking to people. What we were hearing was surprisingly well aligned. While Russ didn't challenge my reading of the project's requirements, he did something very important. He argued that mediation is focusing even more energy on bad behavior; he argued that we don't have the resources to approach mediation; and he argued that it would make it impossible for us to find volunteers for the AH team. That is, he raised a blocking objection in the form of a insufficiently considered issue. He demonstrated that even if we had a consensus, it would be uninformed. We must respond to Russ's concern to move forward. However, we must also respond to the project's requirements that we've identified. Similarly, I understand from Molly that she (and probably the AH team) share a substantially similar concern to Russ. Clearly, we must have the AH team's support for any plan for their scope/approach/role. Several people have told me or assumed that given Russ's concern we'll move forward and not focus on mediation. That's not how building a consensus and listening to people's concerns work. The intersection of "we need responsiveness and mediation" and "mediation is impossible," is not "move forward without mediation." The intersection of "we need responsiveness and mediation" and "mediation is impossible," is "no consensus." Put another way: we're not done talking yet. I hope that surprises no one: this is a hard topic and it's doubtless going to take more than four or five messages to get a proposal that works for the project. We've identified the first conflict between what we want and what we can get. We've identified something to focus our discussions on. I think that is great progress. I think the question we should be asking ourselves is exactly the one Tina posed to Christian: Tina> How do you see mediation helping draw that line? (Not a rhetorical Tina> question, I am honestly curious). Also, there are different ways to Tina> interpret the word mediation, what is your interpretation in this context? [The line of which she speaks is the line around ambiguous areas in the code of conduct.] As DPl I have some thoughts on that, but I'd rather hold back for a bit and see if Christian or anyone else has answers to Tina's question. I understand Russ has some thoughts that I hope he'll be sharing soon. That's where I think we stand right now. If you haven't already, feel free to stop reading here. Above I made the implicit assumption that we're looking for a consensus. That's the approach I'm following now. I think that finding a solution that works for the project, for DAM, for AH, for DPL, and for others involved in the code-of-conduct function is the best way to build trust and a welcoming community. I certainly think we should not give up on trying to find consensus at the first snag. Other approaches are available. In theory, the DPL could delegate a team without project consensus. (Delegating with a consensus that the DPL is making the wrong decision seems like a clear recipe for an override, but delegating with known objections none of them strong enough for an override may sometimes be the best choice.) That said, I'm very unlikely to unilaterally delegate in this instance without something much closer to a rough consensus. We could get to a point where calling a vote is the best way to choose a path forward. And of course, a team with somewhat less de facto power than the Antiharassment team has been assumed to have by a lot of us might not even need delegation or much project buy-in. I've been hearing from both AH and DAM that they'd rather have a team that actually is recognized (and delegated) as a central resource for the project. I concur with that goal. So right now, as DPL, I'm trying to get closer to a consensus. --Sam signature.asc Description: PGP signature
Re: Sounding board for Debian forums?
Neil has been talking about how much the Gnome community has gotten out of discourse. His experience has been positive enough that as an individual developer I'd be interested in using a pilot. I want to stress that I'm not volunteering to do the work of setting up such a pilot. I could imagine such a thing starting out being entire disconnected in phase 0. And trying it out and getting some people to give feedback. If that were sufficiently positive, then working on a pilot where one list were moved to discourse to see how it works.
Re: Results of the Antiharassment Team Survey
> "Christian" == Christian Kastner writes: Christian> However, (this part is a setup for my next answer) for Christian> any given body of people and one unspecific norm, it is Christian> possible for two individuals of said body to arrive at Christian> conflicting interpretations, which calls for one or more Christian> processes to resolve that conflict. >>> Hence, I not only personally like Sam's idea of mediation, I >>> believe it is essential to actually drawing that line. I believe >>> it is essential to leading to improvement. >> >> How do you see mediation helping draw that line? (Not a >> rhetorical question, I am honestly curious). Also, there are >> different ways to interpret the word mediation, what is your >> interpretation in this context? Christian> Answering the second question first: my interpretation of Christian> mediation in this context is a resolution process for the Christian> aforementioned conflicting interpretations, whereby one Christian> or more neutral roles (eg: DPL or A-H) attempt a Christian> resolution in cooperation with the involved parties. Christian> I see this form of mediation helping to draw that line Christian> because (a) it gives all parties an opportunity to have Christian> their side heard, (b) it demonstrates that those drawing Christian> the line have sufficiently engaged in understanding the Christian> problem, and (c) it sends a clear signal that we as a Christian> project aim to solve conflicts cooperatively. Thanks for a well reasoned reply. I have a couple of concerns. First, it sounds like you'd have an interaction where reporters, respondents and the DPL (or AH) might all be talking together. If As a reporter I'm being bullied, I don't want to talk to my bully at all. If the process makes me confront my bully, I'm not going to feel safe. I have no desire to debate with my bully whether their behavior is consistent with our code of conduct. Typically the DPL or the AH team sits in the middle and exchanges separate mails with both sides. Also, typically neither the DPL nor the AH team is entirely neutral. They are more aligned with creating a welcoming community than is entirely consistent with neutrality. Next point. I agree that we need a way to have a disagreement about whether some issue is or is not a violation of the code of conduct. I don't think we want that to be a default part of handling a given issue. Often discussing whether something is a violation tends to escalate the conflict significantly. You have what starts as a relatively simple problem. Someone is aggressive on a list. You ask them to stop. They debate whether they are agressive. Quickly both sides have heals dug in. Having someone who is presumed to be able to interpret the code of conduct helps a lot. Yes you want a procedure for overriding them. Yes, you want to have community discussions about interesting corner cases. But being able to say that a particular behavior strongly defaults to being inconsistent with our code of conduct can really help de-escalate the situation. You can then move onto a discussion of why someone is being aggressive. Enrico's "hey, is everything OK over there." Or my "Would you like help trying to accomplish your goals in a more constructive manner?" Although I also have some significant points of agreement. I do think that spending the time to hear someone is essential. I think we often drop that step and people are bitter about it years later. I find your three lettered points a very interesting set of points. I'm just not entirely sure where in the process they fit. Again, I really appreciate your engagement here. --Sam
Re: Results of the Antiharassment Team Survey
> "Marc" == Marc Haber writes: Marc> On Sun, Jul 14, 2019 at 10:04:43PM +0200, Christian Kastner wrote: >> Answering the second question first: my interpretation of >> mediation in this context is a resolution process for the >> aforementioned conflicting interpretations, whereby one or more >> neutral roles (eg: DPL or A-H) attempt a resolution in >> cooperation with the involved parties. >> >> I see this form of mediation helping to draw that line because >> (a) it gives all parties an opportunity to have their side heard, >> (b) it demonstrates that those drawing the line have sufficiently >> engaged in understanding the problem, and (c) it sends a clear >> signal that we as a project aim to solve conflicts cooperatively. >> >> To me, (a) is an issue of fairness of the process. "The Project >> will draw a line but will hear you before drawing that line". >> >> It is my impression that some of the grievances, or the magnitude >> thereof, result not from actual actions against an individual, >> but rather from not being heard in the process. Marc> +1 >> First, there are numerous reasons why two parties might arrive at >> conflicting interpretations, ranging anywhere from >> misunderstandings to moral differences to incomplete information >> to simple matters of principle. >> >> Second, even if the root cause is correctly identified, there >> might be more than one solution to the problem, with varying >> costs and benefits to the parties but also to the project. >> >> To me, the no-mediation-approach is at best a crude heuristic >> that just targets a specific symptom, regardless of the actual >> cause. Marc> The no-mediation approach is un-inclusive towards people who Marc> involuntarily write things that sound more harsh than Marc> meant. This is a rather common pattern in nerds that we tend Marc> to overreact and overstress things. Not doing any mediation Marc> before making actions such as expelling people from the Marc> project is a violation of the diversity statement. I'm not 100% sure that you and Christian are talking about the same thing. Christian is talking about mediating the question of whether something is a CoC violation or not. You are talking about having a conversation about how to respond when there is a CoC violation. (If it's more harsh than intended in a way where it's not respectful or doesn't create a welcoming community, it's inconsistent with our standards regardless of what you intended. But the best response is often to help you do a better job of expressing what you intended when things are coming across too harsh.) I think that conversation you're talking about--understanding the circumstances and especially for people interested in improving discussing ways to do that--is something I hope our AH process will have. --Sam
Re: farewell
I'll say there is something really unfortunate with the unattended-upgrades packagekit ecosystem. I keep finding that unattended-upgrades takes up 100% of my CPU until I kill it. I have not had a chance to debug enough to submit a bug, but it is infuriating. --Sam
Do we want to try to find consensus before a GR?
I had been hoping to start some discussions on these issues after debconf. I am not really interested in doing so against the backgdrop of a potential GR happening at the same time. Thomas, would you be willing to hold off on potential GR stuff until after I see where we get with consensus? Folks here, would you rather me try and find out how far we can get on debian-devel using methodology similar to the debhelper discussions, or would you rather Thomas draft GR text and look for seconds? --Sam
Re: debian-private leaked on pastebin, worried
Did anyone actually bother to click on the link? How much of debian-private (from when to when) was leaked? If no one even bothered to look, well, that's fine too.
Intent to Delegate: Delegation Advisory Group
[intentionally not signed because this is a comment-seeking draft] Hi. As discussed in [1], I'm forming a delegation advisory group to help me with upcoming delegations. [1]: https://lists.debian.org/msgid-search/tslftm5c1e7@suchdamage.org This group will help me by being a group that I can get advice from even when I need to share confidential information to get that advice. One of the reasons I'm proposing to delegate this rather than treating it informally is to make it clear that these people can be part of the process enough to receive confidential information. This group will help the project by being in a position to know the full details behind a delegation and being able to raise any concerns they have to the project. I want this because I want a group of people I feel comfortable seeking advice from even if I need to include private details in my request. Some people in the project wanted additional people besides the DPL to be able to review the internal aspects of delegations. This is the best approach I've come up with for allowing that review while keeping discussions of specific delegates private. The formal mechanism behind delegations is not changing. Formally, I wouldn't need to consult this group, although if I didn't it would be reasonable for people to ask why. I don't need to agree with the advice from the group, although if they have remaining concerns at the time of delegation, that's likely to spark a lot of discussion. Draft Delegation I appoint the following individuals as a Delegation Advisory Group: * Joerg Jaspert * Steve McIntyre <93...@debian.org> * Theodore Y. Ts'o * Enrico Zini This delegation expires at the end of Sam Hartman's DPL term or when replaced or updated by the DPL. Task Description When requested, the delegation Advisory Group may provide advice to the DPL surrounding delegations. Advice may include advice about the choice of delegates, the task description, or the delegation process. The group may be privy to confidential information such as the DPL's analysis of possible choices for delegates that is not suitable for sharing with the project as a whole. If the group is concerned that a particular delegation may not be a reasonable choice for the project, they are encouraged to share their concerns with the project. The group decides how widely concerns should be shared. The group is delegated the power to introduce or amend a general resolution overriding a delegation that the DPL makes without requiring other developers to second the resolution. Non-Normative Appendix -- Here's how I imagine this working. I include the advisory group in discussions of the delegation. I'd run things by them like my thoughts on delegates and the task description. I'd also be able to talk to them about issues like how fast to go in trying to get resolution on who should be delegates etc or in balancing political issues. I'd expect that in the delegation statement I would note that I'd reviewed the delegation with the advisory group and they didn't have any concerns they wanted to share with the project. I would not expect the advisory group to endorse or lobby for the delegation or write a lot of text to be shared with the project.
Re: Intent to Delegate: Delegation Advisory Group
> "Jonathan" == Jonathan Carter writes: Jonathan> Just one thing that I am /slightly/ confused about (which Jonathan> means that there might be someone else who is too). The Jonathan> topic, and particularly "Delegation Advisory Group" gave Jonathan> me the impression that this would be a group of people Jonathan> that help you out with delegations specifically, That is my intent. Jonathan> but the Jonathan> description in the body seems to imply that this group Jonathan> will be a body of general advisors that you can consult as Jonathan> a springboard on any topic/problem that concerns the DPL? Jonathan> Do I have that right? I'm a bit confused. >Task Description - >When requested, the delegation Advisory Group may provide advice to the >DPL surrounding delegations. Advice may include advice about the choice >of delegates, the task description, or the delegation process. The >group may be privy to confidential information such as the DPL's >analysis of possible choices for delegates that is not suitable for >sharing with the project as a whole. >If the group is concerned that a particular delegation may not be a >reasonable choice for the project, they are encouraged to share their >concerns with the project. The group decides how widely concerns should >be shared. >The group is delegated the power to introduce or amend a general resolution >overriding a delegation that the DPL makes without requiring other >developers to second the resolution. The above text looks fairly delegation-specific to me. What am I missing? To be clear, I could totally see reaching out to those people with non-delegation questions, just as I sometimes reach out to you or various other people in the project. But thatwould be purely informal or would fall under some other delegation (for example talking to members of the debconf committee about DebConf).
Re: Intent to Delegate: Delegation Advisory Group
>>>>> "Norbert" == Norbert Preining writes: Norbert> Hi Sam, I think this is a good idea, but ... Norbert> On Wed, 28 Aug 2019, Sam Hartman wrote: >> * Joerg Jaspert * Steve McIntyre >> <93...@debian.org> * Theodore Y. Ts'o * Enrico >> Zini Norbert> I consider this list too strong an aggregation of duties Norbert> and powers - most of them are already in core positions in Norbert> Debian. Norbert> Aren't there any other DDs you can trust? Unsurprisingly (given that it's the entire reason this all started) I'm unwilling to comment on the delegates I didn't pick. I do think we can talk about the strengths of the team I'm proposing and about whether that meets the project's needs. To your specific concern, I asked Ted to serve exactly because he's not in a core Debian position beyond maintaining packages we all use. I think that's a valuable point of view to get here. Ted also has management experience that is valuable in these situations. I asked Enrico and Joerg to serve because through DAM they have already demonstrated important qualities. They are able to think about disputes and make hard decisions when necessary. But they display compassion, are not too quick to act, and care about stability of the project. Enrico is also one of the people I most turn to within Debian when looking for advice on compassionate empathetic communication, diversity, ane, and promoting underrepresented groups. I asked Steve to serve because he is very much a Debian insider. He has a long history of the personalities and politics involved. He's also good at leadership and has consistently given me good advice so far. I think this team is a reasonable choice for the task description. If others think that there need to be more members who are not involved in core functions, then we can discuss that. I'd need: * People I've worked with and trust to think about people issues. * People who are reasonably responsive to email * People who understand the difference between "this is a reasonable choice," and "this is the choice I would have made." --Sam
Re: Which idiot made Calamares used in Debian ?
> "michael" == michael caron couturier writes: michael> The app is unaccessible for blind users fix your mess michael> before adding crap ... -- Michaël C. Couturier I understand your frustration. It's true that there's not an supported accessible installer that you can run once you've booted a live system. In some ways this is a regression over stretch. Although the installer you could run from a live system previously had a lot of bugs. It's particularly frustrating that this was combined with a bug discovered day of release that broke speech based installs for one of the most popular sound card types in use. I do want to stress that Calamares is only one of several ways to install Debian. We were aware of the accessibility issues with Calamares and would love to see them improve in the future. It's not a requirement that every new feature in Debian be accessible. That said, having an accessible way to install Buster is important. Booting the installer with speech enabled is supposed to do that. In the 10.0R0 release of buster, this is not as reliable as we would like. Fixing this bug is well within the sorts of things we do in point releases. So I do expect installer accessibility to improve for future Buster releases. I also hope that over time Calamares accessibility improves. That said, calling people idiot simply because you cannot use their software is not appropriate on our lists. Again, I do understand your frustration. As a blind developer I'm feeling guilty that I didn't do more testing of the speech-based installer for Buster. Debian is best when we all work to improve it. --Sam
Re: Intent to Delegate: Delegation Advisory Group
> "Adam" == Adam D Barratt writes: I don't think it even means that. > 8.2. Appointment > The Delegates are appointed by the Project Leader and may be replaced > by the Leader at the Leader's discretion. The Project Leader may not > make the position as a Delegate conditional on particular decisions by > the Delegate, nor may they override a decision made by a Delegate once > made. That is, if they introduced a resolution overriding a decision I made, I could not remove that resolution. I cannot change the decision they made. There's a related provision: > 5.1. Powers > The Project Leader may: >1. Appoint Delegates or delegate decisions to the Technical Committee. > The Leader may define an area of ongoing responsibility or a > specific decision and hand it over to another Developer or to the > Technical Committee. > Once a particular decision has been delegated and made the Project > Leader may not withdraw that delegation; however, they may withdraw > an ongoing delegation of particular area of responsibility. Even that doesn't say that there cannot be overlaps in areas of responsibility; the thing that cannot be overidden is a *decision*. However, it is slightly more complicated: >4. Make any decision for whom noone else has responsibility. It has generally been interpreted that once the DPL delegates something under 5.1 (4) that's something for whom someone else now has responsibility and so the DPL themselves cannot act. My interpretation is that the DPL can revise the delegation and potentially even create overlapping delegations, but in general (especially without special wording in the delegation text) cannot themselves act in such a situation. Which is to say that I strongly agree with the principle behind how we've interpreted it, I agree with the practical consequences I can think of, but there are some corner cases (that are unlikely to come up) where I think evolution of our thinking would be valuable. However none of this matters to the current situation. The power in question comes from 5.1(5) not 5.1(4). We'll save the question of whether I could write a delegation such that I delegated all of my 5.1(5) power and retained none of it myself: I'm definitely not doing that here.
Re: Intent to Delegate: Delegation Advisory Group
> "Holger" == Holger Levsen writes: Holger> Hi Sam, why exactly do you think a delegation is useful Holger> and/or needed here? Holger and I discussed that off-list. As a result he made two proposals: 1) Avoid the word privy in the delegation text as that's confusing to a non-native English speaker. I'll do that. 2) He asked me to clarify whether it was the members or the team who had the power to file a GR. In effect he argued that as written the text is unclear on the team's internal process for how they would decide to do something like file a GR overriding the DPL. That is intentional. My understanding of the secretary's interpretation of the constitution is that delegations cannot describe the process by which a team makes decisions that are delegated to the team. I don't agree with all the rationale involved, but I do believe that: 1) Even if there are cases where a delegation can give process details, it is often a bad idea to do so 2) This is a case where the team should have latitude to figure out their own internal process. My hope is that they will either choose that a consensus or majority of the team is required to introduce a GR overriding a delegation. But they could decide that any member can introduce such a resolution, or decide all members must agree, or many other things. My hope is also that they will appoint a member to accept or decline amendments on behalf of the team should they ever introduce a GR. (That gets around an inconvenience that the TC used when exercising similar power). But all that should be up to the team. --Sam
Debian and Non-Free Services
I'm trying to move a thread from -devel. Ian Jackson responded [1] to part of a consensus discussion on Git recommendations. I had said that I think we recommend against the use of non-free services like Github but do not forbid their use. Ian disagreed with this recommendation. I responded [2] noting that around 7% of the packages with a vcs-git in unstable are hosted on Github. Ian said [3] that he was confident if we had a GR to forbid use of services like Github it would pass. He proposed the following text for such a GR. I think such a discussion is better on -project. [1]: https://lists.debian.org/msgid-search/23927.51367.848949.15...@chiark.greenend.org.uk [2]: https://lists.debian.org/msgid-search/tslwoedy93e.fsf...@suchdamage.org [3]: https://lists.debian.org/msgid-search/23930.17192.131171.455...@chiark.greenend.org.uk Subject: Free Software Needs Free Tools No Debian contributor should be expected or encouraged, when working to improve Debian, to use non-free tools. This includes proprietary web services. We will ensure this, insofar as it is within Debian's collective control. For example, Vcs-Git fields in source packages must not refer to proprietary git code management systems. Non-Debian services are acceptable here so long as they are principally Free Software. We encourage all our upstreams to use Free/Libre tools. We recognise that metadata in Debian which describes the behaviour of those outside our community, for example fields which refer to upstream source management systems, may (in order to be accurate) still need to refer to proprietary systems.
Re: Debian and Non-Free Services
> "MJ" == MJ Ray writes: MJ> I have some sympathy with the "send a patch to bugs.debian.org" MJ> view. Do any developers ignore those and tell people to join MJ> github to use its private version of pull requests? I know I MJ> have patches ignored in there but I don't remember being told to MJ> go sign a github contract. I believe we have a strong consensus in the Git Packaging Round 1 thread on debian-devel that maintainers are expected to process patches submitted through the BTS. Telling someone they needed to use Github would be unacceptable in my mind. --Sam
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> "Bernd" == Bernd Zeimetz writes: Bernd> On 7/23/19 7:31 PM, Thomas Goirand wrote: >> 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using >> Git for packaging. Bernd> why is that a reason for a GR? its a question for the policy Bernd> editors. So, I agree that a GR would be the wrong approach if we thought that we could get to a consensus strong enough for the policy editors. I also agree that the policy editors have the technical authority to use a different (non-consensus) process and simply change policy. The policy editors have chosen not to do that sort of thing for a variety of reasons. Personally I think they have judged the needs of the project well. I think that the project would generally be unhappy if the policy editors simply used their best technical judgment to set policy rather than following a consensus process. It seems quite clear that the existing policy process would not come to consensus on any of Thomas's points. So, if we did want to get to a firm policy, I think a GR would be the right tool. I hear that you'd vote against such a GR. Just because you would vote against doesn't mean the GR is a wrong tool. Personally I think that aGR mandating Git on Salsa would fail. I'm trying in a consensus discussion to get to recommendations (rather than requirements) along the lines that Thomas was asking for. Thomas could try to take some of those recommendations to requirements with a GR if he chooses. For several of these recommendations if I cannot get consensus, I will call for a GR myself. --Sam
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> "Scott" == Scott Kitterman writes: >> For several of these recommendations if I cannot get consensus, I >> will call for a GR myself. Scott> What do you think is important enough in this area that you Scott> would rather have people not contribute to Debian if they Scott> aren't willing to do it your way? Nothing. The thing about recommendations is that you don't have to follow them. I think that recommendations leading toward more uniform practices have huge value even if some people don't follow them. And eventually, when we have enough experience it might well be that having more uniformity is worth some people not directly contributing to Debian. I don't know if we'll ever make that trade off and I know we wouldn't (and shouldn't) make it today. --Sam
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> "Mo" == Mo Zhou writes: Mo> As you said, recommendations are merely recommendations. Debian Mo> developers customed to their own workflow may not necessarily Mo> follow the recommendations. However, the recommendation makes a Mo> difference for newbies or newcomers, if their arbitrary Mo> educational resources share uniformed recommends. To some extent Mo> I think debian development is destined to be diversified. Right, and people new to the process is one of the big motivators for me. It looks like we'll get the recommendations via consensus and we won't need GRs. But I think having recommendations available when people are new, when they are looking for what to do when writing new tools, when the trade offs don't matter, is really important. I think it's important enough that it's worth time for a quick vote (and I do believe we can efficiently handle GRs). Besides, I did say in the campaign period I was going to work towards recommendations/policy in this space. You shouldn't be surprised I'll use all the tools available to me to accomplish my goals. I'm always open to changing my mind, but what I've seen so far has re-enforced the idea that more uniformity would be good for Debian rather than challenging it. --Sam
Re: Using Debian funds to support a gcc development task
I'm a bit concerned about your argumentation style in this thread. It feels to me a lot like you're saying that people are wrong simply because they are disagreeing with you. In future discussions, I'd recommend finding a way of having the discussion that acknowledges disagreement and is more focused on understanding positions than judging them or persuading others. Regardless, I think you have your answer. Absent the appearance of significant new support, there is not sufficient interest in spending Debian funds on m68k gcc development. --Sam
Re: Using Debian funds to support a gcc development task
> "Ian" == Ian Jackson writes:
Ian> Charles Plessy writes ("Re: Using Debian funds to support a gcc
Ian> development task"):
>> given the reminders that Debian refrains from paying developers
>> for their time, I wonder if it would still be possible to make a
>> small contribution that expresses Debian's interest and sympathy
>> to your goal, with the hope that our name will help the
>> crowdfunding effort. Something on a scale that would allow us to
>> answer positively to similar requests without putting a
>> significant burden on our finances... Maybe $100 ? This is the
>> same amount as what Debian is willing to reimburse for travel
>> costs to bug-squashing parties, for instance.
Ian> I think this would be a good idea. (And I speak as one of the
Ian> strongest opponents of Dunc-Tank.)
One area where we could clearly show support is by offering to purchase
hardware for someone doing the work.
We have a longstanding practice of helping Debian developers get the
hardware they need to enable their work. (I don't think that would
extend to paying standard prices for a s390 system; while IBM claims
mainframes are more affordable than ever before, I'm reasonably sure
that doesn't mean affordable on our scales).
It certainly would include m68k hardware.
Had I been asked for m68k hardware in this instance, I don't think I
would have even blinked before approving the request.
--Sam
Re: Using Debian funds to support a gcc development task
> "Andreas" == Andreas Tille writes: Andreas> Hi Andreas> On Sat, Sep 28, 2019 at 11:44:26AM +0200, John Paul Adrian Glaubitz wrote: >> So, would -project be willing to support our cause through Debian >> funds? Andreas> Besides other good reasons to say "no" to this question I'm Andreas> wondering whether donators of our money would consider Andreas> supporting gcc on m68k is a good use of their money. Echoing to some extent one of the other responses. I think that we should be prepared to justify how our work meets the needs of our users and is good for free software. How we approach donors probably differs based on their size. I actually think that our large donors are able to understand that one of the reasons they give money to Debian is to do things they themselves wouldn't do. So, yeah, I do think some of the larger donors expect us to spend money on projects that don't get a lot of commercial attention. Currently I don't think our donors (at least those who follow us) expect us to directly fund development, but I think we could explore changing that. I think we need to be open with our smaller donors and work with them to make sure they are OK with what we are doing. For example I think we would need to be very careful to work with our small donors and bring them through the transition if we were going to directly fund projects. --Sam
BSP Reimbursements
TL;DR: Do we want BSP organizers to take on the responsibility of batching together travel reimbursement requests. HI. A while back, I suspended the automatic approval of reimbursements for attending BSPs. You can still ask for approval for attending a BSP, you can't just send me a reimbursement request with no approval. We had a bit of discussion about how things ought to/might work here. Holger proposed that it would make more sense for the people running BSPs to batch approvals kind of like we do for sprints and mini-DebConfs. If we want to do things that way, no action is required on my part. I am very willing to approve such budgets, and even to amend such budgets if it looks like more people are coming. But I do actually want to see them ahead of time, just so I know what's going on. So, if we're generally happy with BSP organizers putting together a travel budget and handling who will get reimbursed, then I think the next step is to write up how to do that on the wiki. I'd appreciate it if someone would volunteer to do that. If you get text together, please drop treasu...@debian.org a note asking for review (that also reaches me). Asking BSP organizers to help with this is great from the DPL side. The only concern is if it pushes the effort involved in organizing a BSP up too much so people don't want to do it. If that ends up being the case I'm happy with some sort of automatic approval process for DDs attending BSPs (and easy approval for other contributors when that makes sense). But let's figure out if we want BSP organizers to handle this first. --Sam
