On Sat, Jun 11, 2016 at 3:00 PM, Michał Górny <mgo...@gentoo.org> wrote: > On Sat, 11 Jun 2016 11:09:39 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> On Wed, Jun 8, 2016 at 11:53 PM, james <gar...@verizon.net> wrote: >> > The grandiose-ness you propose should only come upon graduating from proxy >> > school, imho. >> > user-->strong-users-->proxy-->dev pathway. >> >> Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive. >> Too conservative. >> >> What matters is the contribution, and the result. If you don't like >> how a user makes a contribution, don't accept the pull request, or >> don't merge his package. Simple. If you think that could turn out to >> be just a waste of time for them, help them correct their issues; add >> some documentations to enlighten them and give warnings about wrong >> practices so they don't blame anyone, and so they can decide whether >> they would want to contribute or not given the rules presented; but, >> _don't_ make the steps mandatory. Don't make contributions >> restrictive. > > You're contradicting yourself. How can improving/review of pull request > be non-mandatory, if otherwise we are to reject it? Of course, it all > depends on how you define 'mandatory'. It's not like anybody forces you > to do something, you know.
No, you just misinterpret. You can review pull requests. You can reject stuff, but don't reject them just because some laid-out steps in the documentation has not been followed. Some may not be completely necessary. I'm implying that these "academic" steps may not be completely helpful at all times, and making us follow these things only make making a contribution stiff and restrictive. I'm mainly referring to the strict user-->strong-users-->proxy-->dev pathway that James is encouraging, where it seems like you have to become a proxy developer first (or maybe, prove yourself first; gain first some trust), before you are acknowledged to be able to contribute in a manner that Alexander Berntsen has been suggesting. These stuff imply unnecessary old-fashioned restrictions that aren't "necessarily" helpful to security. It doesn't help encourage users to become active. To make it clear, I'm mostly talking about users who would want to contribute, but doesn't necessarily take pledge on the responsibility of maintaining a package. And isn't that what we are mostly talking about? If we also talk about maintenance-ship, don't we already have the proxy maintainer for that position? > Sure, it may seem like we expect people to fix all the tiny issues with > pull requests but that's just a default profile we're assuming. Many of > the people actually *want* to do that. If you don't, you can tell us > straight ahead and we won't waste our time asking you to. > > I'm also unhappy when a pull request is left open for two weeks because > we asked user to do a simple change, and he doesn't reply. I could've > fixed it myself faster but then the user would lose his chance to do > it. And the worst thing, I don't even know if he wants to! There's nothing I say against that. >> We do already allow people to send pull requests to >> Gentoo portage's repo in Github, but it seems like they generally only >> allow patches that fix current packages, not new features or new >> packages. > > That's not true. The rules for pull requests are pretty much the same > as for bugs. That's great if that's really the case, but a more transparent, less restrictive, and more dynamic system that could attract casual contributors would be better. Something like a web service where their work would be officially indexed so everyone could easily find it, not just the current developers of the current tree snapshot they're trying to push their work to, who may reject it, if it was intended to be pushed. I gave the details about this in my other e-mail. -- konsolebox
