> 3. be careful not to breach any copyright or license terms (yes, we > take those seriously!). >
For a contributor this recommendation is not easily actionable. "I used a tool X and it gave me this code" --- how to make sure I understand the code, this is clear yes I can do that; how am I meant to carefully check for copyright? So maybe it'd be helpful to have a link to some guide, however rough, plus some reading material. Or (am putting a maintainer hat on) maybe we want to ask the contributor to show some analysis. As in, "this code is only a refcounting fix where the origin traces straight to CPython docs" vs "this code can be traced to this Stackoverflow answer" (BTW, what's the copyright status of that?) vs "here's three pages of a Grok-drafted legal analysis". (I planned to stay out of this thread) Evgeni > Scikit-learn has something a bit more explicit: > > > https://scikit-learn.org/dev/developers/contributing.html#automated-contributions-policy > > Before, it felt unnecessary to have such guidelines, because it would be > silly to make a contribution without understanding it (how would you even > come up with the patch). But, now it is entirely feasible to do so. > > I'm also fine with not having any policy and just evaluating each > contribution on its own merits. I do think it's useful to know when tools > were used in generating significant portions of a PR, but it's not strictly > necessary. > > Stéfan > > _______________________________________________ > NumPy-Discussion mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > Member address: [email protected] >
_______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
