I, Miriam España Acebal, apply for upload rights for MOTU Developer.

I am applying because I would like:

• to contribute to Ubuntu more efficiently by reducing the burden on my sponsors and, therefore, eliminating delays in getting my work sponsored.
• to be able to help beyond the server set
• to mentor new packagers-to-be (in the different programs i.e, patch pilot/whatever)

Who I am

I'm a Distro Software Engineer (a.k.a. packaging staff) at Canonical Public Cloud Team (a.k.a. CPC), but when I joined Canonical three years ago, I started at the Server Team. I am attached to the Azure Cloud, so I'm on the front line of dealing with packaging work that involves Microsoft software, like .NET or the WALinuxAgent, but not exclusively.

You can gain insight into my path until I reach this point to applying to Core-dev in my application for Server Set package rights and application for Server Set package rights and see who I am from a career point of view.

My Ubuntu story

This time, in going to tell you how I feel being part of Ubuntu, since I already told the story of how I got here (WIP).

My involvement

Since MOTU, these are all my uploads:

<pending graphic here>

Graphically, here you can see my evolution:

<pending graphic here>

Examples of my work / Things I'm proud of

• <I hope that I've been spent more time in +1 and Patch pilot and collaborative efforts since a successful MOTU application. Also, doing more reviews. >

Speaking about Debian and regarding the different upstream sources we have, I'm now a member Developer of DPDK.

Areas of work

<I'm still work in WALinuxAgent, DPDK MREs and a new agent in azure which I'm packaging (rust based). I hope I've been able to do more mentoring, writing new tutorials/manual and talks >

Things I could do better

<Always room for improvement and I will need to reevaluate just before applying or with the feedback I got from others>

• Timeboxing: It doesn't get better when you have more tasks because you can do more things with your new rights, but I think it is a mixture of experience and pressure.
• Be more direct in asking for the needs I have to progress on my tasks.

Plans for the future

<same that in MOTU for now>

I think CPC lacks a tradition in packaging, and I would like to find a way to integrate this within the team, the people, so that whoever should or wants to can be trained in packaging as well and with the same opportunities as they would in Server/Foundations (I know these are big words).

General

<Same as MOTU for now>

The main idea of me having upload rights is to make CPC a more consistent team on the Distro side, being able to be a direct contact inside the team for complex questions or requests that need advice or acknowledgement from the ubuntu-devel community and directly helping with the usual tasks of a packager-dev person: reviewing, changing, creating, uploading and sponsoring packages.

I'm already helping others in my team with packaging advice or pre-reviews for MPs, and I also got a ping from outside the team for sponsoring openssh because I was (at that moment) the latest one that upgraded the package: these are examples of me not being able to help enough because I cannot sponsor packages.

But, my overall goal is not only to be useful in CPC but also within the Ubuntu developer community: We have a lot of bottlenecks in our distro-processes related to packaging because we are short of human resources and I would like to pitch in when the time comes (+1, Patch Pilot, and all in that I could help as a distro engineering).

What I like least in Ubuntu

< I hope I've been able to help on this since a successful MOTU application, so improving this things and make this list shorter>

I remain unhappy with the knowledge gaps or scattered documentation we have on the path/workflow to being a (PP/Set/MOTU/core)-dev. I know we have initiatives in place (Uploader Reunite/Patch Pilot/...) and I am grateful for that and for the current and past efforts made to bring this all together under one place/source but, for the future, I would like the next generations of uploaders to be able to have answers to the following questions/points as they begin their path to whatever upload-dev they choose to pursue.

* “When you seem ready, is the moment to apply for core-dev or whatever upload-right you’re pursuing…” What is the definition/measurement of “ready”? What is the minimum?

• Actual measurement of “ready”:
  • Endorsements in the application
  • The feelings of the other members concerning the candidate's work.
  • The candidate's interview in the irc meeting (but this is a post-measurement of ready for the candidate)

* Wish to have:

• Could we identify the particular knowledge they should have, as a basis?
  • Debian Policy from A-Z ? (This seems top high bar)
  • What is considered a basic and sufficient level of packaging knowledge?
  • How many different cases should the candidate demonstrate knowledge of, in terms of special/corner cases Does it depends on the team he/she works within?
• They have to know the Ubuntu processes… are all of them available to the public knowledge?
  • What happens after a package’s upload is not documented
  • E.g. The Update_excuses page shows packages that need attention, but where is this noted?

    • It’s part of the description of +1MaintenanceTeam (some of the links there are very obsoletes), which could lead to confusion because that stands for a Team, and +1Maintenance, as talked about, is used day-a-day to refer to the +1 shift.

  • It’s an example of master-padawan knowledge (or onboarding concepts depending of the team)
• Could we identify the (fast) way they have to handle a particular case?
  • Should it include their work-setup/tooling?
    • Should it be aligned with the existing core-dev community? If not, what are the minimums to interact with other core-devs?

• From the last, could we identify a pair package-task <-> workflow?

  • I made this checklist in 2022 when looking an answer to that.

• Could we get a compendium of tools that a packager needs (installations, tips, …) ?
  • It leads others to know tools that can help on his/her day-to-day basis.

This should be broadly speaking, independent of the mentor you have or the team you belong to—as, in my opinion, this influences a lot how difficult it is for the candidate/learner to find this information. I feel this issue is mainly due to the lack of time we have, the fast-paced environment and the nature of Ubuntu itself, but it would be worth trying to improve it.

Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.

Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.

TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)

=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
## Full list of sponsored packages can be generated here:
##  https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi
=== Areas of Improvement ===