Hi!
Super excited to contribute to opencv. Not entirely sure where to begin.
So far I’ve forked the repo and built the binaries using cmake.
Question 1: Does building the binaries run the tests? It looks like it does but not sure.
Question 2: I’m really eager to do C++ work. Should I start by adding new code or by addressing bug fixes? What’s the easiest way to start? If I start with bug fixes, I know where to see new bugs but how can I get context on the bugs? If I’m making new code/features, how can I get context on that as well?
Any other additional information would be great! I’m really excited but also a bit confused. Please link any resources I should read that could help me get up and running!
as far as I know, building is not supposed to run any of the actual tests. what you see at the beginning of cmake’s “configure” step is some probing of the toolchain/system.
if you want tests, you have to make sure they’re being built, and then you need to run them. I’ve never run the tests but it’s probably documented somewhere. if not, there is some CI in OpenCV’s github that you could steal incantations from.
both new code and fixes (and documentation!) improve the world but new code also introduces bugs, so the priority of everyone should always be reducing bugs (and documenting, and fixing documentation)… or at least add code that is good. even if you write code that’ll land in contrib first, strive to make it clean, reasonably documented… all the good things.
the github has a ton of open issues. some are bugs, some are features/suggestions. for many of the issues, you can collaborate, i.e. you can get guidance. you don’t need to know everything or have all the skills. you don’t need to have “own ideas” but you may.
a more “formal” arrangement is Google Summer of Code.
any kind of contribution (that isn’t reasonably trivial) ought to be discussed in the corresponding issue. the core developers (Intel employees and whatnot) will weigh in.
some ideas, off the top of my head:
github always creates a “good first issue” tag. perhaps browse that, or just browse and see what’ll catch your eye
lots of functions check inputs using “assertions”. those expressions are frequently complex and cryptic (conjunctions, so you have to guess which failed) and the messages aren’t much better either. browse Stack Overflow, look for patterns among issues with (-215:Assertion failed), … some of these regularly trip noobs up, and could be a lot more helpful in debugging if broken down into pieces
documentation, in a bunch of places, seems not explicit enough, or misleading, or any number of things that trip noobs up. if the docs for a single function are more than half a screen worth of text, they deserve an extra article or tutorial, and an example, and the api doc itself slashed down and linking to those separate materials.
various platform/device-specific stuff. if you know any specific OS’s APIs well, say macos and its GUI, or you know anything about the GigE/USB3 Vision standards/APIs…
OpenCV.js, it tastes like what the python API used to be in the 1.x/2.x days. terrible. IMHO, and I shouldn’t have much weight in this, numjs (numpy equivalent) ought to be the basis for all the “Mat” stuff.