1. Forum
  2. Usenet
  3. LINUX.DEBIAN.VOTE

  • Question to candidates: About burnout and in-person meetings

    From Nilesh Patra@21:1/5 to All on Sat Mar 29 19:50:01 2025
    Hi,

    I've three questions.

    1. There are many contributors who maintain a large chunk of packages, including
    but not limited to key packages. The bus factor on some key packages is good, on
    others, it's usually one or two people doing a large majority of work.

    What are your views on ensuring that major parts of the system are maintained more sustainably, easing off too much workload on just a few people?

    2. As an extension of previous question, this is also true for some of the DPL delegated
    teams. Lot of work and less bandwidth, and the role in some of these teams are directly
    related to package maintenance. How do you go about it here?

    3. I read in at least 2 of all DPL candidate platforms this year that they intend to
    promote in-person meetings and f2f meetings. That sounds good.
    However, there are always travel constraints for many contributors or even
    time synchronization problems. How do you ensure that people who do not get to attend such
    meetings also get a chance to participate?

    Thanks,
    Nilesh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gianfranco Costamagna@21:1/5 to All on Tue Apr 1 10:30:01 2025
    Hello,


    What are your views on ensuring that major parts of the system are maintained >more sustainably, easing off too much workload on just a few people?

    This is something that should be handled from inside the team itself... Burnout is something
    many people have experienced, and I sadly don't have any answer for that, except
    that we might have some psychologist service that provides support for people with
    too much workload.
    Burning out is not funny, and asking for help is way more difficult.

    2. As an extension of previous question, this is also true for some of the DPL delegated
    teams. Lot of work and less bandwidth, and the role in some of these teams are directly
    related to package maintenance. How do you go about it here?

    I would try to check on a case-by-case basis, there is no general answer for specific questions.
    Burning out is a personal issue, and we should try to help people as well as we spot them.
    Maybe DAM/CT can help identify those, because sometimes being under pressure means
    more critical way of communicating.

    3. I read in at least 2 of all DPL candidate platforms this year that they intend to
    promote in-person meetings and f2f meetings. That sounds good.
    However, there are always travel constraints for many contributors or even >time synchronization problems. How do you ensure that people who do not get to attend such
    meetings also get a chance to participate?

    By scheduling them via multiple people and timezones, we can achieve a goal without many troubles.
    E.g. european people can have chatting with asian and american people without much effort (one
    in the morning, the other in the afternoon).

    G.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Andres Klode@21:1/5 to Nilesh Patra on Fri Apr 4 23:20:01 2025
    On Sun, Mar 30, 2025 at 12:17:22AM +0530, Nilesh Patra wrote:
    Hi,

    I've three questions.

    1. There are many contributors who maintain a large chunk of packages, including
    but not limited to key packages. The bus factor on some key packages is good, on
    others, it's usually one or two people doing a large majority of work.

    What are your views on ensuring that major parts of the system are maintained more sustainably, easing off too much workload on just a few people?

    2. As an extension of previous question, this is also true for some of the DPL delegated
    teams. Lot of work and less bandwidth, and the role in some of these teams are directly
    related to package maintenance. How do you go about it here?

    Frankly I don't see what can be done there externally. Building teams
    takes people to get together and work together, and we can't really
    force them to do that.


    3. I read in at least 2 of all DPL candidate platforms this year that they intend to
    promote in-person meetings and f2f meetings. That sounds good.
    However, there are always travel constraints for many contributors or even time synchronization problems. How do you ensure that people who do not get to attend such
    meetings also get a chance to participate?

    We should also make use of our Jitsi server. All of these are additional
    tools and it's up to the teams that want to use them to use them; we can
    only provide the resources and perhaps say yes or no if someone has
    travel expenses for some critical team meeting.

    In theory you can have remote attendance, but I never found that to be a meaningful option for in-person events. It's very lackluster and you'll
    miss the important conversations outside of what is being streamed or
    what they turned Jitsi on for.

    --
    debian developer - deb.li/jak | jak-linux.org - free software dev
    ubuntu core developer i speak de, en

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Sat Apr 5 17:20:01 2025
    Hi Nilesh,

    Am Sun, Mar 30, 2025 at 12:17:22AM +0530 schrieb Nilesh Patra:

    1. There are many contributors who maintain a large chunk of packages, including
    but not limited to key packages. The bus factor on some key packages is good, on
    others, it's usually one or two people doing a large majority of work.

    What are your views on ensuring that major parts of the system are maintained more sustainably, easing off too much workload on just a few people?

    I've seen that problem last year as well, but I can't claim to have
    found a solution yet. To identify weak spots, I reached out to various
    teams - but I got the impression that the most overloaded and
    understaffed teams are also the least likely to respond, understandably
    so.

    We definitely need to be more welcoming to newcomers. That said, the DPL
    can only offer support and a helping hand - ultimately, the team itself
    needs to engage with the issue and work toward a more sustainable
    structure.

    2. As an extension of previous question, this is also true for some of the DPL delegated
    teams. Lot of work and less bandwidth, and the role in some of these teams are directly
    related to package maintenance. How do you go about it here?

    I often refer to the Debian Med approach - being welcoming to volunteers
    and lowering the barrier to contribution - as a model. It's something
    I've been advocating for years.

    That said, when it comes to DPL-delegated teams, the challenge is
    harder. Unfortunately, I don't have a clear solution as DPL. I can
    encourage openness and offer support, but lasting change usually has to
    come from within the teams themselves.

    3. I read in at least 2 of all DPL candidate platforms this year that they intend to
    promote in-person meetings and f2f meetings. That sounds good.
    However, there are always travel constraints for many contributors or even time synchronization problems. How do you ensure that people who do not get to attend such
    meetings also get a chance to participate?

    That's a real logistical challenge - and unfortunately, long-term travel
    or visa issues aren't something I can solve directly. I did once suggest splitting a team sprint into two locations, connected via video, to help
    avoid visa barriers and also reduce costs for Debian. In that case, the
    team preferred to meet in person, and fortunately all visa applications
    were successful, so the meeting went ahead smoothly.

    In general, I believe we should consider hybrid formats where possible
    and be flexible - solutions will often need to be worked out on a
    case-by-case basis, depending on the team and situation. The key is to
    ensure that participation isn't limited only to those who can travel.

    Kind regards
    Andreas.

    --
    https://fam-tille.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)