Andreas Tille
tille@debian.org |
|
1. Introduction
My name is Andreas Tille. It took me more than 25 years with the Debian account tille to run for DPL.
I am married and a proud grandfather (thanks to my son and daughter-in-law). I am also a father of two adopted daughters (all thanks to Debian) and one of these daughters made me a grandfather again. My background as a physicist has fostered a keen interest in practical applications of IT solutions in science. I have a lifelong passion for various sports, particularly swimming. Concerned about our environment and the climate crisis, I have dedicated myself to planting numerous trees. I am an avid cyclist and have chosen not to own a car, prioritizing sustainable transportation methods.
For me, among other things, freedom means not being available at all times. That's why I decided against owning a smartphone, for instance. Therefore, it is important for you to know that as your potential DPL, there may be times when I am offline and cannot be reached. I value freedom deeply, and I am grateful for the privilege of making choices that are sound with my values.
2. Why I am running for DPL
Short answer
Debian has been a significant part of about half of my life. While contributing packages has been the primary part of my involvement, I feel compelled to give back more to my friends and the community.
Long answers
After initiating the Debian Med project, I have learned a lot about managing a team of volunteers. While I was frequently addressed as the Debian Med leader, I usually refused the term "leader" since I was not elected for this position (and there is no point in having such a leader position for a small team at all). However, I actually fulfilled tasks a leader is expected to do, like establishing a friendly climate amongst the team members and caring for the healthy growth of the team. I learned that leading volunteers is way harder than leading employees, and I consider it a great challenge to motivate volunteers to enjoy working for the team.
In evaluating my capacity to build an effective team, I place value on two qualities that I consider instrumental in achieving success: my background as a physicist and my experience as an athlete. These personal attributes have played a significant role in shaping my ability to lead and collaborate effectively, contributing to my own success in assembling and managing teams. As a physicist, I possess a keen sense to identify logical and sensible solutions. This analytical skill enables me to make informed decisions and navigate complex challenges effectively. Furthermore, my experience as a sportsman has instilled in me a strong sense of persistence and determination. I am committed to applying both of these qualities as DPL, leveraging my analytical mindset to make strategic decisions and my persistence to drive initiatives forward and overcome obstacles.
As you can read in the stats section of my developer page, I have uploaded numerous packages and fixed many bugs. But Debian is not only about uploading packages. It's about technical and social problems, reaching out to newcomers, and ensuring that we remain relevant within the IT universe.
Especially at Debian Conferences but also at other events, I have met many very knowledgeable people whom I would love to work with and from whom I would happily take advice on the new tasks that I might have to tackle.
What makes me afraid about running for DPL
I love Debian because it enables me, as a volunteer, to choose the tasks I love to do. Luckily, there are so many challenging tasks I have enjoyed over the years. I have mostly worked in the background - although making some presentations in various talks has occasionally brought me into the spotlight. Being in the spotlight is something I really don't enjoy, which was one reason I resisted for years when my Debian friends suggested that I run for DPL.
I also anticipate that there are several non-technical tasks awaiting the DPL, which may not be as pleasant as the work I am currently doing in Debian. However, I approach these challenges with optimism. The prospect of establishing a DPL advisory board, from which I can seek guidance and support in navigating difficult questions, alleviates any apprehension I may have about these tasks.
Finally, I am a bit concerned about the workload I'll leave to my teammates since I plan to stop my uploading work to fully concentrate on DPL tasks.
Short summary
I am uncertain whether it's possible to initiate significant changes within Debian during a single DPL term, despite recognizing the need across various aspects. I aim to be realistic and sincere in my commitments, avoiding the temptation to make promises that I may not be able to fulfill. Instead, I prioritize laying a solid foundation for future DPLs to effectively implement necessary changes. I hereby commit to leveraging the experience I gather for the benefit of those future DPLs.
3. Agenda
3.1. Ensuring Debian stays relevant in a changing OS ecosystem
External perception
Sometimes I wonder whether Debian is a victim of its own success by being the most frequently derived distribution. Countless times I've encountered Linux newbies who never heard about Debian but know what Ubuntu is. While this somehow fits my personality as stated above, to stay in the background, it would probably attract more contributors if Debian were more widely known amongst people who do not consider themselves Linux experts.
Reaching Out to Learn
I will try to establish contact with other distributions. From derivatives, I would like to create some kind of wish list for what we, as their upstream, could do better or what we possibly can learn. I also plan to talk to distributions with different technical bases like ArchLinux, Fedora, OpenSUSE, Nix, etc., to see whether we can learn from them to solve problems in terms of organization of work and infrastructure. Maybe we will be able to draw some conclusions, for instance, why ArchWiki is famous for good documentation but wiki.debian.org is not.
Preparing for future
For the Trixie release, we are facing the 64-bit time_t transition. This ensures that 32-bit architectures in Trixie and later will be capable of handling timestamps referring to times beyond 2038. Since other major distributions decided to drop 32-bit architectures, Debian might be even more relevant to work nicely in special hardware applications. That's another challenge we are facing to prepare Debian for the future.
Packaging standards
To uphold Debian's esteemed standard of excellence, I am dedicated to addressing areas where improvements can be made. While we are appreciated for our high quality packages, there is a list of 'smelly packages' (see Debian Trends). My goal is to reduce the barriers to updating these packages and ensure that they meet current packaging standards. This includes encouraging contributors to maintain Git repositories on Salsa, preferably within team spaces, as the default method for maintaining a package.
Outreach
I am committed to investing my energy in outreach projects targeting younger developers to ensure Debian's future relevance. By engaging with and empowering the next generation, we can foster innovation and sustain Debian's position as a leading force in the open-source ecosystem. Through mentorship and educational initiatives, we can inspire emerging developers to contribute, ensuring Debian's continued impact for years to come.
3.2. Work of infrastructure and packaging teams
Infrastructure teams
Debian heavily depends on the work of various infrastructure teams like DSA, the release team, the ftpmaster team, and others. If I am elected as DPL, I will engage with the members of all those teams to identify and solve problems. In the past, I have proposed enhancements for the work of the ftpmaster team. I admit that among several reasons for my DPL candidature, one is to enhance the process of integrating new packages.
Reduce manual work
I am also considering ways to streamline and automate tasks wherever possible. One example that comes to mind is the process of removing packages for specific architectures, which currently relies on manual intervention of ftpmaster triggered by a bug report. While I appreciate the value of having an additional pair of eyes checking dependencies in the past, we now have autopkgtests that signal potential chain of dependency issues. I believe that implementing sensible tooling can significantly reduce manual workload, speeding up processes and providing maintainers with greater control.
Cooperation
In addition to my own packaging work, I have always prioritized strong team maintenance. To assess team sustainability, I have established some team metrics. It has shown that teams in Debian can vary greatly. It ranges from a large number of people cooperating very closely, teams with lots of members just using a common team space and follow a common policy, to teams that are less than a hand full of really active people doing all the work. I hope that I will be able to advertise a cooperative team culture of many active contributors, including creating a friendly environment for new team members. In Blends teams we sometimes succeeded in teaching and involving upstream developers as well as users of the software we are packaging. That's why I am very much in favor of promoting Blends more strongly.
Team culture
I have gained insight into several teams within Debian. I am a big advocate for teams since they lower the barrier to updating and fixing packages that are no longer "private". However, I have also observed packages becoming "team orphaned" when the original uploader silently moved on to other tasks while relying on other team members to maintain the original work. To address this, I would like to promote a stronger team culture to monitor problems within the entire team for every member.
Building redundancy
I envision a future where every crucial task in Debian - whether it's maintaining infrastructure or managing non-leaf packages - is handled by at least two individuals to ensure comprehensive backup and support. History has shown us instances where contributors have had to prioritize personal commitments or unforeseen circumstances over their Debian responsibilities, such as pursuing ultra-marathons or navigating the demands of parenthood. As volunteers may inevitably need to step away from their Debian tasks, it's essential that we establish mechanisms to manage such transitions effectively. This is why I hold reservations about the 'traditional' model of package ownership by a single maintainer.
In other words: If you think single maintainership of packages is the right way to cope with future problems for Debian you should probably rank me below "None of the above".
Packaging standards, salvaging packages
I am a strong proponent of the adoption of Debian-wide packaging standards that aim to streamline workflows and provide easier access for both contributors moving between teams as well as for newcomers. I envision the implementation of standards such as making maintenance mandatory on Salsa, utilizing Salsa CI for continuous integration, ensuring autopkgtests for packages, and leveraging janitor tools, among others. In the long run, I believe these efforts could facilitate package uploads directly from Salsa, further improving efficiency and collaboration within the Debian ecosystem. As a precondition for this goal, I advocate for implementing our salvage mechanism to transfer packages not yet hosted on Salsa to team repositories whenever feasible otherwise in "debian-team".
3.3. Outreach and fostering a friendly environment inside Debian
Face to face meetings
Having worked in Debian for nearly half of my life, I have had the great pleasure of meeting many wonderful people. I appreciate the social environment Debian has established, and I am committed to enhancing it even further. As I value in-person meetings like DebConf, MiniDebConfs, and team meetings, I will support these to the best of my ability. As a follow-up to the BoF Face-to-face Debian meetings in a climate crisis at DebConf23 , I would encourage everyone to minimize air travel whenever possible. Fortunately, I've noticed a tendency among Debian community members to prefer land travel over flights anyway.
Outreach
One of the things I am most proud of in my work in Debian is the fact that my pet project, Debian Med, has attracted an average of one new developer per year of its existence. That's about 2% of the number of Debian developers. This was achieved by participating in outreachy projects and by finding our own means to attract contributors in both directions (upstream and downstream). If I am elected as DPL, I will continue to actively reach out to new contributors and have some rough ideas on how to do so.
Tiny tasks
For instance, I envision organizing a continuous bug squashing party, where contributors come together to address random bugs, thus exploring all corners of Debian. Drawing from my experience as one of the top 10 bug squashers within Debian, I am keen to implement initiatives such as these. Creating a script to select a random bug from the Bug Tracking System (BTS) and featuring it as the topic of a dedicated Matrix channel would be straightforward. This approach could showcase to newcomers the readily accessible opportunities to contribute, serving as a motivating factor. Additionally, I believe that offering guidance on where to seek help within Debian is crucial for attracting and supporting new contributors. I am fully committed to facilitating such efforts, provided that my responsibilities as DPL allow me sufficient time to do so.
Fostering Collaboration
In a similar vein, I am considering implementing autopkgtests for a random package each day within another dedicated Matrix channel. I aim to leverage the expertise of Outreachy students whom I have mentored in these tasks over the past couple of years. Their valuable insights and experience will be instrumental in ensuring the success of this initiative. Additionally, I hope to attract other experienced Debian contributors to join these efforts. By bringing together newcomers and long-term contributors, we can foster collaboration and further enhance the effectiveness of our initiatives.
Diversity
Within the Debian community, there exists an uneven distribution in terms of gender representation and geographic diversity. Currently, there is a notable over representation of male contributors originating from countries typically considered industrialized.
Inclusivity
I have observed that the makeup of our developer community often reflects the diversity present within our user base, albeit to varying degrees. Therefore, it stands to reason that actively working to increase the representation of underrepresented groups among Debian contributors could serve to better align the project with the diverse needs and perspectives of our user base. By fostering greater inclusivity and diversity within our contributor pool, we can enhance the relevance and effectiveness of our project, ensuring that it remains accessible and beneficial to a broader range of individuals and communities.
Lower barriers
As part of my commitment to fostering inclusivity and diversity within the Debian community, I am actively exploring ways to make it easier for newcomers to start contributing. While we have made significant progress in addressing geographic disparities through our translation efforts, there is still room to further strengthen this endeavor. Therefore, I intend to offer support to the localization team to ensure that we continue to improve accessibility for contributors from all regions. Additionally, in tackling gender imbalances, it's crucial to acknowledge the various societal factors at play. For instance, I've encountered the argument that in many cultures, women have less leisure time than men, which can hinder their ability to participate in open-source projects. As a potential solution, we might consider introducing tasks such as bug squashing, autopkgtest writing, and other short-term assignments that require minimal time commitments. This approach aims to lower barriers to entry and encourage participation from individuals with diverse backgrounds and time constraints, as these tasks are self-contained and do not necessitate ongoing maintenance.
Make joining Debian fun and profit
The localization team wiki explicitly mentions the availability of small but valuable tasks, emphasizing that even dedicating just an hour a week can contribute significantly. Similarly, the ideas I've presented above, such as the 'bug of the day' and 'autopkgtest of the day,' offer small, self-contained tasks that can be completed within a short time frame. Moreover, simply observing how others tackle these tasks collaboratively could serve as an engaging entry point for newcomers. Ultimately, my goal is to make joining Debian an enjoyable and rewarding experience.
3.4. Navigating Constructive Criticism: Embracing Feedback for Growth and Success
Learn from people who left
Within the vibrant landscape of the Free Software world, Debian inevitably encounters criticism -- a testament to its significance. While the proliferation of derivatives might initially appear positive, it also signifies unmet needs within Debian itself, implicitly prompting reflection and critique. Past instances, such as the departures of longstanding contributors like Joey Hess and Michael Stapelberg, underscore the importance of addressing criticism. For instance, Michael Stapelberg's comprehensive articulation of reasons for leaving Debian serves as a valuable source of insight and reflection for the community. I will put this article under my pillow, specifically the strong words about striving towards more unification and a cultural shift from "this package is my domain, how dare you touch it" to a shared sense of ownership. I also fully subscribe to the need for unique workflows to possibly profit from Debian-wide changes.
Consulting experts
I find several compelling ideas in this article, that I believe are highly relevant. I am eager to engage with the Debian community to identify longstanding issues that have yet to be addressed. I am committed to facilitating discussions with knowledgeable experts, to actively seek solutions to these challenges.
4. Thank You for Your Trust
If you choose to vote for me, I am committed to ensuring transparency in my work. I intend to maintain a daily log in a public Git repository, provided the information can be shared with a public audience. Additionally, I will send a monthly summary to debian-devel-announce to keep you informed about my activities and progress.
As pillars of our community, your support is paramount to me. Debian holds a significant place in my life, and I am committed to serving you diligently. I place my trust in your judgment to choose the right leader. Thank you for dedicating your time to review my platform and for considering casting your vote in my favor.
A. Changelog
This platform is version controlled in a git repository.
- 0.7: Platform for 2024 DPL elections.