#use wml::debian::template title="Platform for Brian Gupta" BARETITLE="true" NOHEADER="true" #include "$(ENGLISHDIR)/vote/style.inc"
I am running for DPL with a singular goal. The creation of Debian US and EU Foundations. I largely view my candidacy as a referendum on this goal and its details.
Operationally, I would reconstitute the DPL-Helpers team to assist the DPL.
Why can’t we do this all with volunteers, like we do everything else? Although for many technical tasks, it’s fairly easy to do the work as part of our paid day jobs, or as part of other technical roles, we might have because the skills required are many times a natural fit for technologists, for other non-technical tasks, like accounting, lawyering and such, it’s very difficult to find enough people to volunteer to do these things, who are able to give them priority. At the very least, the qualified pool of volunteers that are interested in these issues, but are also technologists who are interested in Debian, is much smaller than for technical or creative tasks.
Why create our own orgs when we have existing ones? We’ve had mixed results over the years working through TOs (Trusted Organizations) that aren’t Debian-focused. It’s no secret that SPI is Debian’s most Trusted TO. It’s also fairly well-known that the service quality provided by SPI to Debian has varied greatly over the years.
Currently, SPI’s service levels have improved greatly, due to their own use of paid help, but there was a time when the service they provided was bad enough that it was hard to justify maintaining the special relationship. Note, this was largely due to limited volunteer cycles, and a wide-ranging mandate, to support many projects.
The biggest challenge of late is that SPI has had a philosophical change. SPI has indicated that they no longer believe that Debian, which was SPI’s founding member project, is their most important project, and all projects must be treated equally.
Some ways that this is manifesting are, 1) the DPL is no longer a special member of SPI invited to all meetings, 2) without informing us, after 10 years of de facto practice, SPI stopped waiving their standard 5% fees on DebConf sponsorship payments, this has cost Debian approx. 16,000 USD since the unannounced change became effective 3) SPI would like to close the Debian Paypal account, for the simple reason that they can’t give all member projects their own Paypal accounts. (Another large SPI member project, PostgreSQL, has their own foundations to deal with these issues.)
In addition, our historically preferred European Trusted Org, FFIS, has become non-functional for all intents and purposes, to the point we now ask people not to donate through FFIS, and have removed them from the list of current Trusted Organizations.
Once the Foundation is operational, an early goal would be for the Foundation to hire a part-time administrator (20 hours per week) who would take direction from the DPL and the board and would be available to assist the DPL, and Debian's various bureaucratic teams, including but not limited to DPL-helpers, Treasurer, and Trademark.
Another goal would be to establish a Debian Europe. France and Switzerland would be at the top of the list of jurisdictions in which to base a foundation, as we have strong TOs there. I would coordinate with both and see if they might want to evolve their organizations into a Europe-wide entity or assist in founding a new one.
Over time, I would expect these two entities to become our primary Trusted Organizations in the US and Europe, but don't expect to end relationships with our current TOs, SPI, Debian France, and Debian.ch.
Some similar entities to look at would be FreeBSD Foundation, the United States PostgreSQL Association, and PostgreSQL Europe.
If you share my goal to establish these entities, please feel encouraged to reach out and let me know, and indicate if you are able to help.
I will perform the following duties that would be expected of any DPL.
In addition, I commit to the following course of action regarding the Foundations:
In addition, I have the following non-Foundation related goals and plans.:
Membership nomenclature:
I don’t believe we should refuse to use the term Debian Developer anymore because someone hijacked it to falsely represent themselves.
As a member of the minority of Debian Developers that joined the Project for contributions unrelated to packaging, when I initially joined the project, I had a strong preference for the term Debian Project Member. However, I came to realize my initial reluctance to use Debian Developer was a manifestation of "Imposter Syndrome", and have grown to use the terms interchangeably, depending on the audience I am addressing. Rarely do I use the term non-uploading Debian Developer, but have, when it's needed for clarity. My choice largely depends on what will be the most understood or useful in context.
I was a little dishearted to hear that Jonathan chose to delay his Project Membership to pursue full uploading rights. I don't fault Jonathan for this, as I've seen other people express this preference before, but it seems a sign of a bigger issue, and makes me wonder if today there is a stigma to being a non-uploading Debian Developer, at least by those pursuing membership.
My ideal long-term future for Debian would be one where the vast majority of Developers only had upload rights to the packages they maintain, as I do not believe that 1000 people all need upload rights to 60,000 packages, and think these rights should be granted very selectively, and only as needed to Developers that have project-wide responsibilities. For example, to active members of Debian Security.
Ideally such rights would be aligned with rights in salsa. It doesn't make much sense that you can upload a package where you cannot edit the source and you can edit the source of a package (e.g. the Debian group = collab-maint) but not upload it at least to delayed queue.
I understand that such a change would be impractical today, and we are very far from achieving a consensus, so it's NOT something I an actively pursuing, but more of a seed for thought, and suspect to get there we’d have to have it be a change we phase in over a long period of time.
Clearly we have work here as a project, but I don't think it's going to be resolved by a GR to stop calling ourselves Debian Developers. I'd prefer to continue to leave that choice to individual Developers and work with DAM and Webmaster teams to make sure the process and documentation for application strongly decouple membership and project-wide uploading rights. (Currently it treats non-uploading status as an anomaly/exception, which may be contributing to the perception.)
I'd like to congratulate Sruthi for running. Although I have no issues with Sruthi's expressed high-level goals, I would very much like to see specifics in order to fully evaluate them. Sruthi is leading DebConf 22 preparations. Even though this is over two years away, there is a lot of preparatory work, and much of it is deadline-driven. Also, it's generally expected that bid teams for future DebConfs are heavily involved in organizing the ones that happen earlier. I would personally encourage Sruthi to run for DPL after DebConf 22, as that would no longer be competing for her time, and would also give her more experience working in the Debian project.