Drawbacks of CLI GUI experimentations and GSoC/D mentoring (was: GSoC project idea)

[Dashamir Hoxha]

On Thu, Mar 21, 2019 at 9:56 AM Bernhard Reiter <bernhard at intevation.de>
wrote:

> Hi Dashamir,
>
> Am Mittwoch 20 März 2019 16:17:37 schrieb Dashamir Hoxha:
> > On Tue, Mar 19, 2019 at 12:53 PM Bernhard Reiter <bernhard at intevation.de
> >
> > > The main problems I see with the idea:
> > > a) How long and by whom would this wrapper be maintained?
>
> > I think that experimentation is worthy too. A wrapper might be easier and
> > more flexible if we want to experiment just to get a better feeling about
> > the new interface.
>
> asking the question in isolation I'll personally think a wrapper is better
> for
> experimentation. And yes, there is value in experimentation. However
> experimenting with something that is unlikely so be ever stable or
> recommendable (because of the unlikeliness of upstream adoption and
> missing
> long term maintenance perspective) should be very clear to all
> participants.
>

I agree.


> To me there is only a small chance that this experiment will lead to
> useful
> knowledge. There maybe some knowledge gain, but without good chance to get
> an
> implementation done that actually helps users.
>

I still think it is worth to give it try as a GSoC project, provided there
are interested mentors and at least one interested student. The mentors
don't have to be developers, they can also be experienced gpg users. The
work done by the student during GSoC does not have to be integrated to the
main project, it is completely fine to throw it away even if the summer
project itself is considered successful.


>
> Note that this is just my perspective I don't know how the main GnuPG devs
> think about this.
>
> > By the way, Google Season of Docs is around the corner:
> > https://developers.google.com/season-of-docs/
> > Maybe this can be a good opportunity to improve the docs (about WKD etc.)
> > The best part of GSoD is that it is not limited to the students, so
> > hopefully the quality of the resulting work will be better.
>
> Given that it is quite hard to write good documentation, it is almost like
> software engineering, I'll expect the same problems as with GSoC.
>

The difference is that the people that you select for the GSoD project do
not have to be students, they can actually be software engineers. It is
like you are hiring a contractor for 3 months but the bill is payed by
Google (if you are satisfied with his job). You can also hire people from
the community who are already working voluntarily on that (documentation)
project.


>
> > > so to me it is doubtful that a student can handle this in 3 months.
>
> > That's why the mentors are needed.
>
> The time a well qualified mentor may need to help a student produce a
> usable
> result can be higher than the time that she would need to implement or
> write
> the result by herselfs. So Werner could possibly implement what two
> students
> can do in the time he would need to teach and afterwards correct one
> students
> work. The justification for this mentor would be to either learn something
> themselfs or to hope that a student sticks around and repays the
> investment.
> Both is not the best path. If you want to learn something else than
> teaching
> you could again implement this yourself and if we want to find new
> developers, we should seek for people that have a long term interest.
>

That is completely true. Only a long term interest may make the effort
worthy for a mentor.
But as I mentioned above, the mentor does not have to be Werner, and there
could be more than one mentors (per project). Actually there should be more
than one mentor, it is a recommended practice, and some organizations even
require that there are at least two mentors per project (for obvious
reasons).

Best regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190322/599482b4/attachment.html>