2012/4/29 Michael Schwendt <mschwendt@xxxxxxxxx>: > On Sun, 29 Apr 2012 19:31:43 +1000, GG (Guido) wrote: > >> > That's no new responsibilities. Sponsors have always been expected to do >> > that. With pkgdb, it requires "watch*" access to the packages. Else >> > it requires subscribing to the scm-commits list and filtering by >> > username/packagename. I've done that, and I've been aware of sponsors >> > who have done that, too. >> >> I wasn't aware of that; if it isn't a best practice, but a must do, >> the wiki page >> http://fedoraproject.org/wiki/Package_sponsor_responsibilities should >> be updated. > > You've found a section in the Wiki that isn't pretty. :-) > There's this other page: > > https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Sponsoring_Someone_for_Fedora_Package_Collection > > | You should be sure to review their commits to the Git repository for > | how they look, and consider watching their Bugzilla activity at least > | for a while (Account->Email->Users to watch). > >> >> More sponsors should bring more control, not easier membership. >> > >> > Too vague. Please expand on that. >> >> If this page is updated (I have no idea): >> https://admin.fedoraproject.org/accounts/group/members/packager/*/sponsor?order_by=approval >> the sponsors group has not grown as a function of packages, nor as a >> function of package maintainers. Possibly because of the sponsor is a >> provenpackager thing, possibly because that was meant as "we need X sponsors >> to take care of the Y new maintainers requests we get each given time window". > > Rest assured, no such variables X and Y are in use anywhere related to the > packager sponsor group. Potential sponsors either nominate themselves or > get nominated by somebody else: > > https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor My apologies for deviating the thread earlier. I would address this issue in a different way: 1) Assigning a sponsor to a new potential contributor takes a lot of time from an active 'sponsor' and there's no ensurance the contributor will go through it and succeed; in case it fails, it's 'wasted' time that could be used into something more productive from the sponsor. 2) Motivational issues: this are important, either from the sponsor and from the potential contributor; While for the potential contributor slow response times can break his motivation, for the 'sponsor' motivation can be affected by non-responsive contributors or people who just 'disappear' This are probably the most relevant factors, sponsor's workflow and motivational issues. There's no easy fix for it, so my suggestion would be to face the current issues from a whole different perspective: a) Packages should be owned by a group of people and not necessarily from a single person; face this as the real 'owner' of the package is "X", where "X" stands for the group of all co-maintainers of the package, which can be coordinated by a SIG; b) Introduce a more collaborative way; Imagine I want to get package 'foobar' updated; The step would be to encourage the current person to file a bug report requesting the update and provide already a git pull with the changes; When it comes to review one of the persons which maintains the package can review the git pull request and merge it/rebuild it or request further changes. This is the fase where there's know-how transiction and everyone would be allowed to submit changes to Fedora without being a packager. The review still happens and isn't bound to a single person, but instead to a group of persons, which should reduce the heat. c) Such a method would also mean that packages are harder to get orphaned out, since theres more people looking after them; d) This should provide a faster review and response; e) This should allow that the 'trust' escalation on potential contributors still happen; f) The integrity of the project and quality of the packages should be maintained as there's always a higher review; g) People can escalate in trust based on past contributions to the project, and this allows people with less technical skills to still be able to contribute in a secure way to the project; furthermore, it allows collaboration and provides also a know-how transfer from more experienced users to newcomers; I know this isn't perfect, but for me, such a method would be far more easier; instead of being nagging people to do rebuilds/updates, etc, potential contributors should actually be able to submit code directly and having a group of people to review it and merge it when accepted... Would this make any sense and in your opinion would it be possible ? > >> But I am not saying that a sponsor should be turned to a forced >> comaintainer for the time being, either. > > That wouldn't work well in all cases anyway. There is no requirement for > sponsors to have indepth knowledge of the software the sponsoree has > packaged. Not even the first package the sponsor has reviewed. Doing > packaging and reviewing a package is one thing, being intimately familiar > with the packaged software is another. Review-time testing of the packaged > software is only a SHOULD in the guidelines. It is assumed that the > package submitter is familiar with the software and that the reviewer > is sufficiently familiar with packaging to not break the software by > making false recommendations. ;) > > -- > Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64 > loadavg: 0.02 0.05 0.05 > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- Nelson Marques // I've stopped trying to understand sandwiches with a third piece of bread in the middle... -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
