Re: DDG Tasks Bug Bounty Proposal
Steve Dougherty writes: > I don't think anyone is proposing that new developers get push access > or bypass review by existing developers. We're all in agreement that > it would not be acceptable. Matthew's question of how to avoid long > review delays doesn't have a great answer; I can't think of anything > beyond keeping the tasks much smaller than purge-db4o was. We can request that the pull request be designed to be easy to review. If it takes more than an hour for review, that’s too long. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: DDG Tasks Bug Bounty Proposal
I don't think anyone is proposing that new developers get push access or bypass review by existing developers. We're all in agreement that it would not be acceptable. Matthew's question of how to avoid long review delays doesn't have a great answer; I can't think of anything beyond keeping the tasks much smaller than purge-db4o was. Sent from ProtonMail mobile Original Message On May 9, 2017, 3:21 AM, wrote: On Tuesday, May 09, 2017 09:12:21 AM x...@freenetproject.org wrote: > On Monday, May 08, 2017 04:57:10 PM Ian wrote: > > There is also a trust issue, since we would probably need to give them > > access to source repos and other things - and it would be irresponsible to > > do that with someone we know nothing about. > > For security reasons I don't think any of the core contributors will accept > giving direct push and/or release privileges to someone who hasn't been on > the project for years, me included. > > If we hire a stranger they will have to commit to their own repository and > send pull requests just like any other unknown new contributor. > > Further, for code quality reasons, payment should only be sent once their > code has been reviewed and accepted by the core team. > Freenet is a complex project, we cannot blindly merge code from someone who > hasn't proven to be familiar with the codebase yet. Proving this takes > years. I'm sorry, I wasn't clear enough: You seemed to say that hiring a non-anonymous person would solve this problem. I meant to reply that knowing their real name does *not* solve it: Any new contributor will have to prove their skill by sending PRs for a long time, anonymous or non-anonymous. Direct push/release access and payment is not an option IMHO.
Re: Potential source of funding and bug finding
On Mon, 2017-05-08 at 20:09 +, Freenet wrote: > To qualify for these rewards, a project needs to have a large user > base and/or be critical to global IT infrastructure. Which of those two requirements do you think that Freenet fulfils? signature.asc Description: This is a digitally signed message part
Re: DDG Tasks Bug Bounty Proposal
On Tuesday, May 09, 2017 09:12:21 AM x...@freenetproject.org wrote: > On Monday, May 08, 2017 04:57:10 PM Ian wrote: > > There is also a trust issue, since we would probably need to give them > > access to source repos and other things - and it would be irresponsible to > > do that with someone we know nothing about. > > For security reasons I don't think any of the core contributors will accept > giving direct push and/or release privileges to someone who hasn't been on > the project for years, me included. > > If we hire a stranger they will have to commit to their own repository and > send pull requests just like any other unknown new contributor. > > Further, for code quality reasons, payment should only be sent once their > code has been reviewed and accepted by the core team. > Freenet is a complex project, we cannot blindly merge code from someone who > hasn't proven to be familiar with the codebase yet. Proving this takes > years. I'm sorry, I wasn't clear enough: You seemed to say that hiring a non-anonymous person would solve this problem. I meant to reply that knowing their real name does *not* solve it: Any new contributor will have to prove their skill by sending PRs for a long time, anonymous or non-anonymous. Direct push/release access and payment is not an option IMHO. signature.asc Description: This is a digitally signed message part.
Re: DDG Tasks Bug Bounty Proposal
On Monday, May 08, 2017 08:29:45 PM Matthew Toseland wrote: > Having said that, review capacity has been a problem in the past. My > purge-db4o work was delayed for an entire year, for example. How can we > minimise this? Just because our existing core contributors with review privileges aren't up for hire to implement the planned new features perhaps doesn't necessarily mean that they wouldn't accept at least being paid to review them once a new external developer has done the larger work of writing the code? I feel like their primary problem is that they already have a job and thus lack the time for being hired for Freenet full-time development, but reviewing code takes less time than writing it. Arne? Florent? Steve? You? signature.asc Description: This is a digitally signed message part.
Re: DDG Tasks Bug Bounty Proposal
If the USA would consider paying anonymous people money laundering then I'd agree that we shouldn't risk this. Nevertheless you raised an interesting issue which will also be relevant to non-anonymous employees, I'd like to say something about it: On Monday, May 08, 2017 04:57:10 PM Ian wrote: > There is also a trust issue, since we would probably need to give them > access to source repos and other things - and it would be irresponsible to > do that with someone we know nothing about. For security reasons I don't think any of the core contributors will accept giving direct push and/or release privileges to someone who hasn't been on the project for years, me included. If we hire a stranger they will have to commit to their own repository and send pull requests just like any other unknown new contributor. Further, for code quality reasons, payment should only be sent once their code has been reviewed and accepted by the core team. Freenet is a complex project, we cannot blindly merge code from someone who hasn't proven to be familiar with the codebase yet. Proving this takes years. signature.asc Description: This is a digitally signed message part.