Re: Introducing code owners
On 07/11/2017 06:21 AM, Rich Bowen wrote: On 07/11/2017 03:41 AM, Bertrand Delacretaz wrote: I still think the name sucks, in the end IIUC it's not much more than "code review notifications" which can be useful to have. Sure. And if it's used well, it could be great. But names are powerful things, and shape attitudes. To a beginner, approaching a project that they want to participate in, the notion that code is "owned" by someone can be a real deterrent. +1 to that. --Jacob - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Introducing code owners
On 07/10/2017 06:03 AM, Rich Bowen wrote: On 07/07/2017 09:39 AM, Shane Curcuru wrote: I think "CODEOWNERS" is too strong a term; they should have been more descriptive with CODEREVIEWERS or the like, since these aren't necessarily owners of a file or project. That might be useful feedback for github, but since they've already rolled it out, I doubt they'd change it. Perhaps change it to COOKIELICKER instead? Every project I've worked in where someone "owned" a particular feature/file/method/document, that thing has ended up either getting neglected (because nobody else was willing to touch it) or caused fights (because someone else *was* willing to touch it). I think Shane's point is that the feature doesn't actually imply ownership; it implies required review. That can be twisted into something negative, like code silos and cookie licking, or it can be used to automate what some Apache projects are already doing. I think it's a nice concept, if poorly named. Has anyone actually tried to use the functionality? From their documentation on the feature, you don't have to put a single person as the reviewer -- you can specify a GitHub group. So, to give a concrete example, httpd could protect their 2.4.x backport branch with the group of httpd committers, protect the docs/ directory with httpd-docs committers, and put security-critical files on review with the security team. The automation means that it's harder for things to slip through the cracks: if that "documentation-only" pull request suddenly requires a security review, something is *wrong*. Can it be abused? Certainly. Will it be abused? Probably. Does that mean it sucks? Nah. --Jacob - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Results: ASF Committer Diversity Survey
On 12/20/2016 09:51 PM, Alex Harui wrote: I (and maybe others) want to eliminate the argument that the response rate was too low to be used to draw conclusions. I agree; this was one of my first thoughts when I saw the survey response rate. --Jacob - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Does GSoC help develop communities?
I think I agree with both of you... On 12/05/2016 09:41 PM, Ulrich Stärk wrote: I have seen way too many metrics being misused to justify the wrong actions ...measuring the wrong thing at the wrong time or in the wrong way can be *extremely* harmful, yes... On 12/05/2016 01:07 PM, Daniel Gruno wrote: - Do we spend any ASF resources on this (I'm thinking money/paid time here)? - Do we enter into any form of legally binding contract with GSoC? If the answer to both are 'no', then I'll certainly not stand in the way of people wanting to do this - but if even one of them is 'yes', then we (the PMC at the very least) owe it to the foundation (and ourselves) to justify this on a recurring basis. ...but it is still important to justify why the ASF is doing something, especially if contracts are on the line. What about a softer metric to start with: "What percentage of past and current Apache GSoC mentors feel like their involvement has been beneficial, either for their associated Apache projects or for the greater open source community?" Both high and low percentages here are, IMO, instructive and useful in their own right. A middle-of-the-road answer means we'd have to dig into the "why do you feel that way?" question more to reach any conclusions, but again, that's still useful. (Compare, for example, with the metric "What % of code developed by GSoC students actually becomes a part of the project codebase at the end of the project?" In this case, an extremely high percentage could mean that GSoC is "successful", or it could mean that GSoC code gets into codebases regardless of its quality, or... Likewise, an extremely low percentage could mean that GSoC is "unsuccessful", or it could mean that GSoC is being used for more experimental efforts that are providing value to projects in some other way, or...) --Jacob - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Does GSoC help develop communities?
On 12/05/2016 08:15 AM, Stian Soiland-Reyes wrote: Perhaps ComDev can act like a prpject visitor. (Not auditor or inspector!) "No one expects the ComDev Inquisition!!" We can make a wiki page with a randomised list of all ASF projects, a quick checklist (smaller than maturity model) and just go through them one by one and raise issues/pull requests for any small community encouragement issues we find. Is that too intrusive? Perhaps a bit off-topic for this thread in particular, but in all seriousness, I like this idea a lot. As you've noted, older projects and established developers don't always know which parts of their projects need "newbie improvement" -- after all, they've already figured it out for themselves. --Jacob - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Open Source (Licensing) book
On 09/21/2016 03:25 PM, Stefan Sperling wrote: http://producingoss.com/ might be a good fit. This was the book that immediately came to mind for me, as well. --Jacob - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
