6 ms·
This looks like something that could catch on, especially if you're already compartmentalizing projects into libraries, that alleviates a lot of hesitation in s
by git-pull 9y ago
This looks like something that could catch on, especially if you're already compartmentalizing projects into libraries, that alleviates a lot of hesitation in sharing a codebase. It's good to see that NDA's are involved as a layer of protection.
There are things that a human can suggest that computers can't. Such as a refactoring suggestion.
Here are a few ideas:
- Consider adopting a standard like EditorConfig (http://editorconfig.org/ http://editorconfig.org/) for reviewers to have compliant indentation out of the box
- For Enterprise packages: perhaps there can also be an opportunity to sub-contract out features and write tests?
- Consider experimenting internal CI tools (like as done in open source projects) to scan for obvious/low-hanging fruit automatically
- Scanning for / suggesting package updates
- Provide QA / audit for a large open source project for exposure
- Security auditing
Here are things that are good to hear:
- Static / Linting: things like vulture, flake8, etc. seem like a nice thing to stick to. It's good that these linters have configuration files to it
- lyal 9y agoThanks much! A lot of good notes; some initial reactions: Completely agree re: editorconfig. Very necessary to prevent bikeshedding. We're actually building a dedicated review IDE. Part of our roadmap is to offer open source projects code review -- not just for exposure, but to work with reviewer standards on. We're definitely interested in security review.