I think that requiring everyone to test a pull request before opening a new one will just grind development to a halt. Although it has to be done, nobody likes testing. Automated testing relieves a lot of this, and many of the pull requests are involved enough to require extensive manual/integration testing by themselves.
On Thu, Feb 18, 2016 at 7:38 AM, Wilder Rodrigues < wrodrig...@schubergphilis.com> wrote: > Hi all, > > > It’s been a long time, but the Wolverine is not dead yet. ;) > > Currently we have 175 opened PRs, which we all agree to be a lot, given > the fact that few people, if any, are testing/merging them. I have been a > bit off the radar, but from next week I will start helping to get some of > those PRs tested and, hopefully, merged. > > In order to get the community working as an unit, I would like to propose > the following: > > * One should only create a PR after testing an existing PR. > - By testing I mean… testing. Not just looking into it and saying > “LGTM”. Manual tests should also count, with screenshots attached to the PR. > > That will make those with test environment pitch in and help, and in > addition might also decrease the frenzy for creating PRs which occasionally > won’t be tested within a month time - or longer. > > For others not creating PRs that often, like me, we should help testing at > least 1 PR per week. > > Being a bit more blunt now, if a PR is created but the person does not > contribute with testing an existing one, the new PR should be closed. > > What do you think? > > Cheers, > Wilder -- *Jeff Hair* Technical Lead and Software Developer Tel: (+354) 415 0200 j...@greenqloud.com www.greenqloud.com
