= Proposal topic =
Formalize the path to sponsored by being a co-maintainer of existing packages and also extend it to cover new unknown contributors.
= Overview =
There is a need for a simpler process for people interested in joining to helping with maintaining existing packages. Technically this already exists to some degree on a case by case basis (which myself is an example of) but needs to be formalized, defined and extended to support new unknown people coming in.
= Problem space =
The current official sponsoring paths scares away many potential packaging contributors. Quite often there is people who feel they are fully up to the task of co-maintaining a package or packages they have interest in, but then reads the documentation on how to join and reacts "uhm... this looks complicated" and decides it's not worth the effort.
Currently the documented path involves submitting a new package, which often isn't applicable (package already exists). It's non-obvious what one needs to do to join as an maintainer of an existing package.
= Solution Overview =
Allow package owners to request to allow not yet sponsored persons access to their package, and document this path in [http://fedoraproject.org/wiki/PackageMaintainers/Join PackageMaintainers/Join] for how to join the project.
Additionally in this case I would propose to give package owners part of the sponsor responsibilities for guiding and helping the new one to get used to Fedora contributor responsibilities, perhaps in cooperation with a sponsor. The package owners are often well suited for this task as they know the package being maintained and also know reasonably well how Fedora packaging works. This obviously do not work for already orphaned packages, but works well for packages where the owner has interest in the package.
Persons coming in via this path should not automatically get full sponsored status uonless an existing sponsor can vote for the credibility of the person. Which basically means that if they want to submit a new package it would still go via the same sponsor review path as today, with added feedback from the package maintainer(s) the person have been working with. Also means that when a person of this type asks for access to a package then the package owner should clearly see that the person is not yet fully sponsored and only registered as co-maintainer of packages X.
After a year or so (or on request by package owners) the person should be reviewed for full sponsored status, based on how well he has fulfilled his job as a co-maintainer by feedback from relevant package owners or sponsors which have monitored the process.
= Active Ingredients =
fas, sponsors responsibilities, [http://fedoraproject.org/wiki/PackageMaintainers/Join PackageMaintainers/Join] document or policy, pkgdb
= Owners =
hno? Note: not entirely sure what owner means here..
This adds to the already existing schedule topic "Alternative paths of membership advancement".
Implementation rough outline:
Removing from meeting agenda, as this was approved.
So this was approved, but Jesse had some other ideas about this. As far as pkgdb and cvs implementation, this is a non-trivial task on the CVS side, but I've already written the code to make it so over there (by converting the world to filesystem ACL's rather than the avail file, a non-trivial change to be sure), and the backend of the pkgdb code. What I've not yet done is the frontend, but I'd like to know if we're to proceed with this path or something else.
One problem with the CVS filesystem ACL code is that it has no idea what has changed, and setting ACL's for lots of branches of ~6,000 packages is quite expensive. While it can take a list of packages to inspect via the command line, it's got to get that list from somewhere, so there's some architectural decisions to be made there as well.
My thoughts that this seems like a social problem, not a technical one. A newly sponsored packager only has access to the packages which people explicitly grant them rights to, or packages they own. Since every new package has to get reviewed, there is little chance for a packager who was sponsored to work on one package, would be able to bring in a bad package down the road and somehow get it through review. When a package owner wants to grant access to an as of yet unsponsored packager, and they themselves are not a sponsor, they should contact one of the existing sponsors and arrange to "co"sponsor said unsponsored packager. They can reach an agreement upon who sponsors, and which packages are opened up to them. Any further opening up would be matters between the newly sponsored packager and other packagers. I really really do not see the need to complicate our ACL system even more by adding yet another layer of authorization, particularly one that is being implemented in a way that will not work in the future with dist-git.
I ask that FESCo reconsiders the solution. I don't disagree that the problem exists, I just disagree with the proposed solution.
We are going to revisit this at the next meeting (2010-02-16)
per proposal at FESCo's last meeting:
Fesco approved the draft wiki pages and the idea of just adding a any packager can commit button to pkgdb. (no seperate group needed).
Toshio: Can you get that added to the wiki and implemented?
a post to devel-announce might also be good.
Should we also mail sponsors and packagers directly?
The wiki has been implemented for a year now, not sure if an announcement ever went out. However, people still aren't clear on if/how to get sponsored if all they want is to comaintain a package. I think we need to have an explicit section on this page about that:
Simply having a section there stating the status quo isn't enough, though, as people still need to attract a sponsor if the package maintainer isn't a sponsor. If the idea is that in the current world, a package maintainer is responsible for the packagers that work on their package, do we want to look into making every packager a sponsor? Another possibility is to setup a more formal system of "Do you want user Foo to comaintain your package but you need someone to sponsor them? File a ticket with fesco stating that you will be responsible for mentoring them and one of the fesco members will do the sponsorship for you."
Here's a sample of new policy for the How to get sponsored page. It takes the more conservative route I described above.
== Become a comaintainer ==
Another way to enter the packager group is by comaintaining a package that is already in Fedora. To get sponsored this way you need to convince the current owner of that package to let you comaintain the package and they will act as your mentor -- teaching you how to package properly in Fedora and how to use the tools available for building and distributing packages. To get an owner to agree to this you may need to demonstrate that you have some understanding of packaging already or at least, that you are eager to learn. Submitting patches on bug reports, preparing updated packages if the maintainer is behind on creating an update, or otherwise communicating with the maintainer that you are willing to help are ways to show that you are worth the package owner's investment to train you.
In some cases the package owner is a sponsor in the packaging group and can sponsor you themselves. If they are not a sponsor, have the package owner open a ticket in the fesco trac instance stating that they are a package owner who would like you to comaintain their package. They agree to be responsible for mentoring you in how to follow the Fedora Packaging Guidelines and use the tools Fedora provides for building and pushing packages but need someone to sponsor you since they are not sponsors themselves. A FESCo member can sponsor you into the packager group once that agreement for mentorship exists.
The suggestion in comment 10 was approved.
Toshio is going to write up in the wiki and then we will announce it.
Keeping this open for those actions.
Writeup done. I ended up touching these three wiki pages:
The little blurbs link to the How to get sponsored page.
Announcement sent. Thanks.
I guess we can close this now? or is there any further actions?
to comment on this ticket.