Greetings Team, One of the agenda items for the LTS meeting on IRC this week is a discussion of the "Package Owner" proposal. Essentially, this is a new role being proposed to help improve the outcomes of LTS/ELTS work on packages which could benefit from more direct attention be a particular individual or team and the continuity that comes with that.
Attached to this email is a preliminary write up of the proposed role. If you have questions or feedback, please bring them to the IRC meeting or share them via a reply to this mail. Regards, -Roberto -- Roberto C. Sánchez
The "Package Owner" Role ======================== What Is It? ----------- One of the challenges with ensuring the packages receive increased attention is overcoming the natural tendency within a group to assume that "someone else will take care of it". It has been observed that at times packages will languish in dla-needed.txt or ela-needed.txt, requiring FD to issue calls for "someone" to step in and handle a package. Sometimes this works and sometimes not. The role of "Package Owner" is proposed as a way to overcome the "someone else will take care of it" problem by ensuring that selected packages have a designated owner or owners. It is also expected to help create a degree of continuity such that the owner or owners are aware of ongoing issues and special considerations related to a particular package. The closest analog to the proposed "Package Owner" role is that of "maintainer" of a package in Debian. The maintainer can be a single individual, more than one individual working together loosely, or a more formally organized time. The "Package Owner" role in LTS/ELTS would function in a very similar way. However, because of the scope of work done in LTS/ELTS the "Package Owner" does not have the same degree of authority and autonomy when it comes to matters outside the scope of LTS/ELTS security work. For instance, a "Package Owner" would not be permitted to make unilateral changes to a package in unstable. Who Will This Involve? ---------------------- To be a "Package Owner" for LTS/ELTS it is necessary to be a paid contributor. To reduce complexity and overhead, the ownership responsibility for a package in LTS and ELTS (assuming it is supported in both LTS and ELTS) will rest with the same individual or group. Additionally, in some instances it may make sense to group packages together and treat them as a single entity for the purposes of ownership, such as postgresql-*, openjdk-*, etc. There may be instances where being a paid contributor alone is insufficient, for example, if the owner of a particular package requires access to non-public information (specific customer details, security embargoes, etc.). These special situations will be addressed as they are encountered. How Will Owners Be Assigned? ---------------------------- Once a package is identified as being in need of an owner, a coordinator or manager will reach out to one or more individuals, or to the contributor group as a whole (depending on the package or packages in question), and make an invitation to take on a package as its owner. Additionally, if a contributor is aware of a package which in their estimation would benefit from having an owner, they are welcome to raise the matter with a coordinator or manager for consideration. Benefits and Drawbacks ---------------------- The proposed ownership model has some benefits as well as some drawbacks. The benefits include: * Continuity of knowledge concerning the history of a package * Improved ability to leverage external/additional resources as appropriate * Reduced incidence of packages being "forgotten" and of problematic updates (i.e., those resulting in regressions) * The potential to leverage external help to free up internal contributor time for other tasks * Improved efficiency That said, there are some potential drawbacks as well: * Perception that only the "owner(s)" can work on a particular package * Packages getting stuck when the "owner(s)" are not able to attend to them promptly Note that the "Package Owner" proposal is not meant to be a complete solution to every issue with updating LTS and ELTS packages. Rather, this is intended as a low friction approach to improving outcomes without creating a great of additional bureaucracy. In particular, this seeks to leverage the excellent work which individual contributors perform by further empowering them in specific ways pertaining to specific packages. Suggestions for improvement are most certainly welcome. Expectations and Responsibilities --------------------------------- The "Package Owner" concept brings with it some expectations and responsibilities. On the one hand, management (managers, coordinators, and front desk) should expect that if a package is added to dla-needed.txt and/or ela-needed.txt following initial triage, that the owner(s) will be assigned the package and then notified of the assignment. For packages with a specified owner or owners, this should largely eliminate the problem of packages languishing for an extended period of time. Management is responsible for ensuring that packages which need owners are assigned them, and also for ensuring that package owners are attending to their packages in a timely and appropriate fashion. Management is also responsible to step in should a package owner become non-responsive. For the "Package Owner" the expectations and responsibilities require a bit of explanation. Based on initial feedback, some contributors are more interested in performing technical work while others are less interested. As a result of this variation, it is useful to consider the different ways in which an owner might handle a package. For a more technically inclined package owner, the expectation is that when a package is triaged into dla-needed.txt and/or ela-needed.txt and the owner is notified then work will commence in within an appropriate time interval. What is considered appropriate is dependent upon a number of factors and it is largely up to the package owner to determine this. If the owner cannot commence work within an appropriate time interval then the owner is responsible to find someone else who is able to perform the work. For a more managerially inclined package owner, the expectation is that when a package is triaged into dla-needed.txt and/or ela-needed.txt and the owner is notified then the owner will begin coordinating the work that needs to be done. This coordination might involve reaching out to trusted third parties with specific expertise in a package (i.e., paid consultants, unpaid volunteers, helpful upstreams, etc.), or seeking aid from within the LTS/ELTS paid contributor group. For more managerially inclined owners, it is especially good to seek LTS/ELTS contributors who are new to the group to work on a package. This allows the owner (presumably an experienced contributor) to mentor the newer contributor through the process, and allows the knowledge base of the team to grow and mature. In either case, it is expected that package owners will be aware of the current state of the packages which they own, that they will be diligent to keep the notes updated in dla-needed.txt and/or ela-needed.txt, and that they will provide appropriate follow-up for any work which they outsource (whether to paid consultants, unpaid volunteers, helpful upstreams, etc.). Additionally, if the owner is responsible for a package for which there currently exists an arrangement with a third party, then it is entirely possible that the owner primarily coordinates the work to be done by an external entity, reviews the work, and publishes the appropriate packages and announcements for LTS/ELTS. This allows the owner the ability to offload the task to an external entity and then to use the resulting time surplus for other tasks. Additional Discussion --------------------- It is expected that package owners will treat their responsibility as something of a priority. If there is a known absence pending or some other reason that a package owner will be unavailable or unable to respond to new issues, then that package owner must coordinate among the contributors to ensure that there is appropriate coverage in the event that new issues need to be handled. Conclusion ---------- At present, this proposal is only being circulated for comments and feedback. It is not yet implemented and will likely change from what is described here prior to implementation.
