Re: [Boost.GIL] GSoC 2020 Project 1 - Seeking Mentor

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-01-31 16:47:27

On Fri, 31 Jan 2020 at 03:24, Ayush Bansal via Boost
<boost_at_[hidden]> wrote:
> On Thu, Jan 30, 2020 at 8:01 PM Mateusz Loskot via Boost <boost_at_[hidden]> wrote:
> > On Thu, 30 Jan 2020 at 15:05, Ayush Bansal via Boost <boost_at_[hidden]> wrote:
> > >
> > > For my competency test, I was interested in doing the implementation of
> > > convolution filter and use it to detect edges.
> >
> > FYI, please watch
> > https://github.com/boostorg/boost/wiki/Google-Summer-of-Code%3A-2020
> > as the GIL competency test section may receive some updates during next
> > days.
>
> In order to get familiar with the GIL, I tried implementing a basic version
> of Erosion and Dilation. It would be really great for me if you could take
> a look at it and tell me if I could use it as part of my Competency test
> Any other suggestions are also welcomed.
> https://github.com/ayushbansal07/GSOC_Boost/blob/master/morph.cpp

Since your competency test solution aims to implement an algorithm
an actual feature with potential of being useful as part of the GIL,
then I'd suggest you to consider submitting it as a proper PR.

IMHO, PR efforts come with numerous benefits for GSoC candidates, e.g.:
- Makes you actively participate as part of the project community
- Teaches the actual real life development workflow
- Teaches workflows involving Git, GitHub
- Teaches iterative workflows of PR reviews
- Motivates you to aim for quality, e.g.:
     - compliance with contributor guidelines (makes you actually read them!)
     - necessity to work on tests (and, ideally, documentation)
- Presents your code as part of the big picture, if/how it integrates
  with the library and not as a random project written using random
  build system following random personal conventions and preferences
- Makes it easier for others to review your code
- Uses of common CI builds to verify your code
- Gives your efforts public visibility

Don't be shy about submitting a PR with an unfinished code,
a proof of concept,
a code that you have more questions than answers about,
a code that you have not tested using all toolsets/environments, etc.

Have a look at PRs submitted by students last year
https://github.com/boostorg/gil/pull/259
https://github.com/boostorg/gil/pull/258
If you read through the commentary you should get a basic
understanding of how things work :-)

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net