3 ms·

tl;dr: if you're not on a bleeding edge rolling release, this will probably be fixed before the affected versions hit you. If not, read below for a summary of w

• db48x 4y ago
  Man, reading systemd issue #25269 is like pulling teeth. Person A reports that he wants to hibernate after being suspended for 30 minutes, and that it used to work and is now broken. Person B doesn’t understand why, so asks why 30 minutes and not 4 hours? Person A thinks Person B is judging them for their personal preferences, and says that they chose 30 minutes because they like it. Person B then deduces that Person A is an idiot who thinks that the systemd default behavior should be determined Person A’s personal preferences. What Person A really wants is to pull their laptop out in the morning and have it still be at 90% charge instead of 5% (or 0%!) charge. Given no other configuration options, they chose to have it hibernate after 30 minutes. They would not choose to configure the delay to 4 hours because then the battery would be a lower the next morning. Then Person C comes along and tries to correct the misunderstandings by suggesting that there’s no reason why it cannot do both at the same time. Person B is still focused on improving safety, and still sees the configurable time as unsafe (because someone might configure it for longer than their battery can last), and misunderstands Person C. Person C has to return and reexplain, with amplification from Person D, that the default behavior should be to hibernate when the battery is low for safety, but also to hibernate at the expiration of the timer, if the timer fires first. This would satisfy everyone, even the weirdos who want their battery to stay charged when they’re not using their laptop. Person B finally understands and says that would be fine. Elapsed time? 6.5 excruciating days, plus two more days for Person E to push a patch. Then Persons F, G, H, I and J chime in to add their own amplifying explanations, congratulations, thanks, etc. Even I wanted to re–explain it to Person B.
  • Zuiii 4y ago
    If I have a choice between fixing an issue locally vs interacting with a large upstream project - who tend to always have a Person B (someone who isn't equipped to handle the subject but will nontheless form a premature opinion and attack anyone who challenges it), then I ALWAYS fix it locally because it takes more effort to convince Person B. Sometimes they silently fix it in a couple of years later, other times another project comes in and renders their project (and my local fix) obsolete. Perhaps projects should have policies and codes of conduct that protect them against this type of harmful behavior.
    • db48x 4y ago
      Lol, having a policy against miscommunication is not going to make it less common. Edit: note also that there were _two_ harmful misunderstandings here: Person B misunderstood Person A, but Person A also misunderstood Person B’s question. A Code of Conduct is not going to help.
      • pxc 4y ago
        A code of conduct might be able to help, but not by banning rudeness or defensiveness. If a code of conduct succeeds as part of as an effort to develop or maintain a generous culture of patience, assuming good faith, thanking others for their work, and gentleness regarding mistakes, that could short-circuit some of these interactions. Like when B highlights that this change in suspend behavior was not only documented but '6 months of work', it kinda seems like they were defensive or irritated because they felt like their hard work to implement a useful feature was being discounted. If they felt like that work was recognized, they might have been less defensive about defending the original idea for their future and more curious about why the bug reporter wanted the behavior they wanted. Same thing for Person A; if they had been less inclined to read Person B's question as critical, they might have explained themselves more completely earlier on. A code of conduct treated as a rulebook to cite against people would definitely not help, but a skilled moderator pointing to a policy that encourages people to slow down, listen, be curious, or to a shared statement of values that makes people feel relaxed and safe, or to something that evokes pride in their shared participation in the project... that could have gotten this resolved more quickly. Some projects have maintainers/authors whose kindness, deliberateness, or thoughtfulness seems to flow downstream to later contributors as a norm. Something like a code of conduct could serve in part just to encode that explicitly as a community aspiration. But yeah you can't just say that being confusing, confused, frustrated, or frustrating is g allowed lol