[kde-community] Closing the kde-core-devel mailing list

[Valorie Zimmerman]

A few in-line responses below:

On Tue, Aug 12, 2014 at 12:23 PM, Kevin Ottens <ervin at kde.org> wrote:
> Hello,
>
> On Monday 04 August 2014 20:36:44 Vishesh Handa wrote:
>> Random Idea:
>
> Heh, someone with too much time at hand? :-)
>
> Note that I generally find that fiddling with lists is generally generating
> quite some boring work across the board.
>
>> How about we close the k-c-d mailing list?
>
> I think others voiced it but IMO it is a very bad idea...
>
>> It's main purpose used to be to discuss kdelibs changes, but now since we
>> have kde-frameworks, the mailing list seems less useful. We already have
>> kde-devel for other generic kde stuff.
>
> ... which is based on wrong assumptions.
>
> As Albert et al. pointed out, k-c-d is used for community wide technical
> discussions: great plans touching several projects, tooling changes (the great
> scons vs cmake battle for instance), kdereview process tracking, reaching the
> "core" people (hence the name) aka most actives in the community (in their
> project or several projects). I like to define it as the "town hall" of the
> tech people in KDE.
>
> For some reason, the kdelibs related discussion still lingered there although
> it was becoming its own thing. Since KDE Frameworks started the noise level of
> that particular project would raise risking to drown the other useful
> communications of k-c-d, hence the creation of k-f-d to avoid that risk
> (there's another reason, see below).
>
> kde-devel is for people discussing general development. It's more the seeking
> general help area.
>
> (I think the above paragraphs should cover the "recall the purpose of each
> list" that Aaron was calling for, at least that's my version of it, I'd like
> to believe I've been around enough to not be too far off)
>
> So to get back to the original question, should be close kde-core-devel? I
> hope it's clear that "bloody hell, no!!!" Don't know how you'd feel about it,
> but for a community like our loosing its "town hall" that would be a disaster.
> For instance, Kevin Krammer's example of having a mean of contacting largely
> for gauging the need of a scripting BoF is spot on. I hope it won't get to
> that point, but k-c-d would still have value if it was the only kind of
> traffic on it.
>
> Some then argued that maybe we should close kde-frameworks-devel. That at
> least makes more sense to me. That said, I'm of the opinion we should keep it
> open. Remember above I mentioned there was another reason for its creation? I
> will get to it soon. ;-)
>
> Choosing to close k-f-d depends how you see its purpose...
>
> If you see its purpose as the mailing list for the "kdelibs to KDE Frameworks
> transition *project*", then yes it can be closed once this transition is over
> (probably not now though, as kdepimlibs still didn't transition yet, so I'd
> expect the traffic to raise again).
> If you see its purpose as the mailing list for the "KDE Frameworks *product*"
> then it shouldn't be closed.
>
> I fall in the second category, because the reasoning for opening that list was
> first to avoid generating the noise on k-c-d during the transition (first
> reason already mentioned above) but also to have a place for third parties
> interested in KDE Frameworks only to participate and get informed (second
> reason).
>
> Obviously, it is too early to know if it is worth it having k-f-d for people
> interested in KDE Frameworks only as this audience didn't have time to form
> yet.

This week at Randa we've been writing a KDE Frameworks Cookbook. I
should put "book" in quotes, because really we are finding and fixing
or creating documentation for the Frameworks, and developing a process
for that documentation to be dynamically kept up-to-date (by keeping
it in the various git repos) and allowing it to be *written once,
displayed everywhere*. Our ultimate goal is to have the tools
available for everyone to be able to find the docs needed from apidox,
in Techbase, in PDFs for printing, as ePub for your device, or as a
book to be printed up for giving away at say, a Qt Developer conf.

Our effort (like inqlude) is to spread the word far and wide about
Frameworks. And we would hope that those devels inclined to join the
k-f-d list will do so, and feel welcome. We would rather that than
comments on the "book" itself, since it is also easily available to
clone from git, edit, commit, and push [1].

> Now, since it has been mentioned in the thread as well, there is the question
> of review board emails... I'm increasingly of the opinion that they shouldn't
> end up on k-f-d and k-c-d. I used to think otherwise, but it's becoming
> increasingly clear to me that it hinders other type of discussions. Which
> means that the third parties audience I was talking about won't even get a
> chance to form if we don't change that somehow. Back in the days we had
> bugzilla traffic on devel mailing lists, then it got moved away in specialized
> lists, it looks like the review board traffic should have the same fate.
>
> OK, it's longer than I wanted to so I will stop soon. Sorry for the length,
> but I thought that just coming with a bullet point of actions without the
> reasoning behind it would be disrespectful.
>
> Here is the bullet point list just in case it could be useful:
> 1) Don't close k-f-d or k-c-d;
> 2) Restate the purpose of our lists, maybe on wiki;
> 3) Move current review board traffic to some other list (kde-frameworks-
> reviews and kde-core-reviews perhaps? no strong opinion there);
> 4) Wait for the full kdepimlibs transition into KDE Frameworks;
> 5) Wait a few more months after that (something like six months, maybe longer,
> depends how fast we reroute reviews in fact);
> 6) If a third parties and new KF5 specific contributors audience formed on k-
> f-d then keep it, otherwise close it in favor of k-c-d[*].
>
> Thanks for reading all the way down if you reached that line. ;-)
>
> Cheers.
>
> [*] Note that if that audience never forms we probably failed at something as
> the reason for modularizing aggressively was also to attract such new blood.

We hope to aid in that, and aid the devels in their own promotion
efforts as well.

> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> KDAB - proud supporter of KDE, http://www.kdab.com

Valorie, for the KDE Frameworks Cookbook team

1. git clone KDE:scratch/garg/book (we'll get a real repo soon)
-- 
http://about.me/valoriez