[kde-community] Should we allow non-KDE projects to participate in GSoC under KDE?

Martin Klapetek martin.klapetek at gmail.com
Fri Feb 5 14:40:39 UTC 2016

On Fri, Feb 5, 2016 at 8:42 AM, Teo Mrnjavac <teo at kde.org> wrote:

> On Thursday, February 4, 2016 11:53:48 AM CET Ivan Čukić wrote:
> > > Just FTR, we don't give away our own slots, but we ask for slots after
> > > we decide how many projects we are going to select.
> >
> > And with that I'm completely fine.
> I just found myself physically shaking my head at some of the more
> authoritarian-bent emails in this thread.
> In KDE we have a GSoC team that's been taking care of GSoC and other
> student
> programs for years now, and these people are intimately familiar with GSoC
> dynamics on slot allocation and are thoroughly aware of the costs and
> benefits
> of allowing external projects to take part in GSoC under the KDE umbrella.

That doesn't mean you can do whatever you want though,
even more so when it's a small group with no outer access.

> It would be toxic to try to micromanage the Krita team, the sysadmin team
> or
> the WikiToLearn team: KDE has historically worked best when those who do
> the
> work decide how it's done.
> So here's a novel idea: how about we let the GSoC team do what they are
> good
> at and come up with their own policies and decisions in GSoC-related
> matters?
> At best, any concerns should be brought up with them on the relevant
> mailing
> list, rather than appointing ourselves as overseers in this thread.

I did last week and where I got told to post it here. After all
it should be a community decision.

Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20160205/d7e0999f/attachment.html>

More information about the kde-community mailing list