[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Formal request to set up a KDE Discourse instance
From: Philippe Cloutier <chealer () gmail ! com>
Date: 2021-02-28 19:32:03
Message-ID: aa1d0936-b538-d3ea-2a91-019c0eb905be () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Greetings,
Thank you for bringing this up Nate. The previous decade surely hasn't
been phpBB's best.
I must thank Eike for his wise reply. I also fail to see anything
unacceptable about Nate's request. But I will still thank everyone for
avoiding further damage, and because you all inspired me - albeit likely
involuntarily - to blog a geekultural essay which I hope will make this
"diskourse" (pun intended) even more konstruktive. I'm attaching here
its essence, an algorithm in the form of pseudo-Java.
Coming back to Nate's request, I've never used Discourse yet, but I'm
confident that Discourse and phpBB are currently the 2 best free
software forum engines available. And the wind has clearly turned in
Discourse's favor. That being said, to my knowledge Debian does *not*
use Discourse. In fact, at this time, Debian does not even *package*
Discourse (although to be fair, it no longer packages phpBB neither - it
hasn't since the previous stable release).
One tool I do know is Docker, and I do agree that if Discourse has an
absolute dependency on a tool of that maturity, we have an orange flag.
I've never noticed any other application with an intentional absolute
dependency on Docker.
But the worst flag I can see is that Discourse seems to have no ITS. Of
course, that's not the case for phpBB, so I would consider that as a red
flag for an actual migration. Such a lack would obviously be a huge
issue per se, but also speak quite poorly about Discourse's maturity.
Anyway, if you think this deserves being duly evaluated at this point,
the proper way to formulate such requests is via our ITS. In this case,
you can file a ticket against the sysadmin product, or against
forums.kde.org, which I believe is best if the goal is indeed to change
that site's engine. There are 2 ways to do that:
1. Report each issue which you find problematic in forums.kde.org
(phpBB) and which Discourse would solve or alleviate
2. Report an issue about forums.kde.org using a sub-optimal engine, a
bit like https://bugs.kde.org/show_bug.cgi?id=417941. It is
important to formulate such tickets carefully though - failing that,
they are particularly likely to be mishandled.
I would say none of these is clearly better than the other. #1 can be
considered cleaner / more useful, but #2 will likely require less time
if your efforts truly result in a quick migration.
It's also possible to combine both. It would be a shame to do that
without cross-referencing the relevant tickets. Bugzilla offers a
"Blocks" relationship between tickets, which would enable us to mark #1
issues as blocked by the ticket from #2, except for the fact that there
are in fact many more ways to fix each individual issue than migrating.
Jira offers a much more less restrictive (and much vaguer) "relates to"
relationship. Having that on bugs.kde.org would be helpful... but
meanwhile, relations can be mentioned in the text.
P.S. It seems you forgot to Cc whoever "Adam" is.
Le 2021-02-23 à 19:34, Eike Hein a écrit :
> Hey,
>
> This all sounds much too confrontational :-). Come on everyone, we can
> do this much better.
>
> Ben, I don't think Nate's request implies prioritization. For folks
> outside a particular team it can be difficult to follow what the team
> has on their plate at the moment; you probably also wouldn't know the
> same about Nate's VDG/QA space.
>
> Everyone knows that sysadmin is working hard all the time, but it has
> to still be possible to do roadmap planning. In fact it's one of the
> best ways to avoid getting overcommitted in the future. Declaring a
> goal and/or agreeing to work on it in the abstract doesn't mean it has
> to be done straight away or rushed, but it e.g. allows attracting
> contributors to the goal to get the work done, as also seen in the
> thread already.
>
> The idea of adopting Discourse as a replacement for the old forums has
> been around for a number of years, and I would say it's probably
> become more compelling with time. KDE Forums hasn't seen a lot of work
> and Discourse has risen 8n popularity and familiarity. It's at least
> worth investigating with an open mind now. If the investigation finds
> road blocks (capacity, technical, others) we can discuss them further
> - constructively, without being strangely afraid others will make
> decisions without them. The only way that happens is by not communicating.
>
> I would suggest making a rough proposal on what this really means
> operationally. How would we migrate, how would we sundown, what sort
> of work would Discourse need, what sort of setup and infra are
> required. Sysadmin should ideally provide input there based on
> experience, implementation policy, etc. Then we know what we need,
> what we don't have, and what we think we should do about it.
>
>
>
> Cheers,
> Eike
>
>
>
>
> On February 24, 2021 1:21:14 AM GMT+01:00, Nate Graham <nate@kde.org>
> wrote:
>
> On 2/23/21 4:07 PM, Nate Graham wrote:
>
> On 2/23/21 3:53 PM, Ben Cooksley wrote:
>
> May I take this as a formal request from yourself that
> Gitlab CI is deprioritised and delayed? Based on the
> extremely frequent requests we get concerning it in
> #kde-sysadmin I am not sure if your request here is in
> line with general community consensus. Also, be aware that
> Sysadmin currently has other infrastructure level projects
> underway needed to get us off Ubuntu 16.04, which are
> currently delayed because we haven't had anyone volunteer
> to assist us with adding support for OAuth2/MyKDE to
> Reimbursements. Based on the above, I assume you are also
> requesting that we delay this, and accept the
> corresponding security issues that will accompany it when
> Ubuntu 16.04 loses support in the coming months in order
> to get this actioned?
>
> Hmm, I don't see where I suggested any of those things. If you
> folks are really that overloaded, we need to figure out how to
> fix that. A workload that exceeds available resources doesn't
> help anyone. The last time this came up, people called for
> additional volunteers to assist. Did that end up bearing any
> fruit?
>
>
> Anyway I apologize if my tone was off. I wasn't meaning to accuse
> sysadmins of anything, and I guess I didn't realize how overloaded the
> team is right now.
>
> That being what it is, perhaps a more productive line of discussion
> would be to ask: "what do you need from us so that these things that
> need to happen, and that we all want, can reach fruition faster?" You
> don't have to suffer in silence! :)
>
> Nate
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Philippe Cloutier
http://www.philippecloutier.com
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Greetings,<br>
Thank you for bringing this up Nate. The previous decade surely
hasn't been phpBB's best.</p>
<p>I must thank Eike for his wise reply. I also fail to see anything
unacceptable about Nate's request. But I will still thank everyone
for avoiding further damage, and because you all inspired me -
albeit likely involuntarily - to blog a geekultural essay which I
hope will make this "diskourse" (pun intended) even more
konstruktive. I'm attaching here its essence, an algorithm in the
form of pseudo-Java.</p>
<p><br>
</p>
<p>Coming back to Nate's request, I've never used Discourse yet, but
I'm confident that Discourse and phpBB are currently the 2 best
free software forum engines available. And the wind has clearly
turned in Discourse's favor. That being said, to my knowledge
Debian does *not* use Discourse. In fact, at this time, Debian
does not even *package* Discourse (although to be fair, it no
longer packages phpBB neither - it hasn't since the previous
stable release).</p>
<p>One tool I do know is Docker, and I do agree that if Discourse
has an absolute dependency on a tool of that maturity, we have an
orange flag. I've never noticed any other application with an
intentional absolute dependency on Docker.<br>
But the worst flag I can see is that Discourse seems to have no
ITS. Of course, that's not the case for phpBB, so I would consider
that as a red flag for an actual migration. Such a lack would
obviously be a huge issue per se, but also speak quite poorly
about Discourse's maturity.</p>
<p><br>
</p>
<p>Anyway, if you think this deserves being duly evaluated at this
point, the proper way to formulate such requests is via our ITS.
In this case, you can file a ticket against the sysadmin product,
or against forums.kde.org, which I believe is best if the goal is
indeed to change that site's engine. There are 2 ways to do that:<br>
</p>
<ol>
<li>Report each issue which you find problematic in forums.kde.org
(phpBB) and which Discourse would solve or alleviate</li>
<li>Report an issue about forums.kde.org using a sub-optimal
engine, a bit like <a class="moz-txt-link-freetext"
href="https://bugs.kde.org/show_bug.cgi?id=417941">https://bugs.kde.org/show_bug.cgi?id=417941</a>.
It is important to formulate such tickets carefully though -
failing that, they are particularly likely to be mishandled.<br>
</li>
</ol>
<p>I would say none of these is clearly better than the other. #1
can be considered cleaner / more useful, but #2 will likely
require less time if your efforts truly result in a quick
migration.</p>
<p>It's also possible to combine both. It would be a shame to do
that without cross-referencing the relevant tickets. Bugzilla
offers a "Blocks" relationship between tickets, which would enable
us to mark #1 issues as blocked by the ticket from #2, except for
the fact that there are in fact many more ways to fix each
individual issue than migrating. Jira offers a much more less
restrictive (and much vaguer) "relates to" relationship. Having
that on bugs.kde.org would be helpful... but meanwhile, relations
can be mentioned in the text.<br>
</p>
<p>P.S. It seems you forgot to Cc whoever "Adam" is.<br>
</p>
<div class="moz-cite-prefix">Le 2021-02-23 Ã 19:34, Eike Hein a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:F87AAE16-F695-439E-AB2A-DEA5FCE4E4F0@kde.org">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hey,<br>
<br>
This all sounds much too confrontational :-). Come on everyone, we
can do this much better.<br>
<br>
Ben, I don't think Nate's request implies prioritization. For
folks outside a particular team it can be difficult to follow what
the team has on their plate at the moment; you probably also
wouldn't know the same about Nate's VDG/QA space. <br>
<br>
Everyone knows that sysadmin is working hard all the time, but it
has to still be possible to do roadmap planning. In fact it's one
of the best ways to avoid getting overcommitted in the future.
Declaring a goal and/or agreeing to work on it in the abstract
doesn't mean it has to be done straight away or rushed, but it
e.g. allows attracting contributors to the goal to get the work
done, as also seen in the thread already.<br>
<br>
The idea of adopting Discourse as a replacement for the old forums
has been around for a number of years, and I would say it's
probably become more compelling with time. KDE Forums hasn't seen
a lot of work and Discourse has risen 8n popularity and
familiarity. It's at least worth investigating with an open mind
now. If the investigation finds road blocks (capacity, technical,
others) we can discuss them further - constructively, without
being strangely afraid others will make decisions without them.
The only way that happens is by not communicating.<br>
<br>
I would suggest making a rough proposal on what this really means
operationally. How would we migrate, how would we sundown, what
sort of work would Discourse need, what sort of setup and infra
are required. Sysadmin should ideally provide input there based on
experience, implementation policy, etc. Then we know what we need,
what we don't have, and what we think we should do about it.<br>
<br>
<br>
<br>
Cheers,<br>
Eike<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote">On February 24, 2021 1:21:14 AM
GMT+01:00, Nate Graham <a class="moz-txt-link-rfc2396E"
href="mailto:nate@kde.org"><nate@kde.org></a> wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<pre dir="auto" class="k9mail">On 2/23/21 4:07 PM, Nate Graham wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px \
solid #729fcf; padding-left: 1ex;">On 2/23/21 3:53 PM, Ben Cooksley wrote: \
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px \
solid #ad7fa8; padding-left: 1ex;"> May I take this as a formal request from yourself \
that Gitlab CI is deprioritised and delayed?
Based on the extremely frequent requests we get concerning it in
#kde-sysadmin I am not sure if your request here is in line with
general community consensus.
Also, be aware that Sysadmin currently has other infrastructure level
projects underway needed to get us off Ubuntu 16.04, which are
currently delayed because we haven't had anyone volunteer to assist us
with adding support for OAuth2/MyKDE to Reimbursements.
Based on the above, I assume you are also requesting that we delay
this, and accept the corresponding security issues that will accompany
it when Ubuntu 16.04 loses support in the coming months in order to
get this actioned?
</blockquote>
Hmm, I don't see where I suggested any of those things.
If you folks are really that overloaded, we need to figure out how to
fix that. A workload that exceeds available resources doesn't help
anyone. The last time this came up, people called for additional
volunteers to assist. Did that end up bearing any fruit?
</blockquote>
Anyway I apologize if my tone was off. I wasn't meaning to accuse
sysadmins of anything, and I guess I didn't realize how overloaded the
team is right now.
That being what it is, perhaps a more productive line of discussion
would be to ask: "what do you need from us so that these things that
need to happen, and that we all want, can reach fruition faster?" You
don't have to suffer in silence! :)
Nate
</pre>
</blockquote>
</div>
<br>
<div class="k9mail-signature">-- <br>
Sent from my Android device with K-9 Mail. Please excuse my
brevity.</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Philippe Cloutier
<a class="moz-txt-link-freetext" \
href="http://www.philippecloutier.com">http://www.philippecloutier.com</a></pre> \
</body> </html>
["FingerSaver.java" (text/plain)]
import HumanEmulation.Feeling;
import HumanEmulation.Judgment;
import Life.*;
import Internet.Message;
// FIXME: Unlikely to build without --leniency=max
public class FingerSaver {
public static void main(String args[] ) throws Exception {
Message incoming = Message.getLatest();
incoming.read();
if (! incoming.replyWarranted()) {
System.exit(Feeling.HAPPY);
}
if (incoming.isUrgent()) {
incoming.processRegular();
System.exit(0);
}
Thread thought = new DeepThinker(incoming);
thought.start();
// If we use Thunderbird with XNote++, we could store quick ideas about what \
to reply as a note. String skeleton = thought.getFirstReplyIdeas();
Message initialVersion = null, previousVersion = null, latestVersion = null; \
// Reply versions do {
if (latestVersion != null) {
previousVersion = latestVersion;
if (initialVersion == null) {
initialVersion = latestVersion;
}
}
Integer tongueTurns = 7;
feeling = Feeling.getCurrent();
tongueTurns = tongueTurns + feeling.getAnger();
/* Increase quality proportionally to the number of readers
Also reduce collision risk
TODO: Make logarithmic rather than linear */
tongueTurns *= Message.getPeopleInDiscussion();
if (Message.isEmail()) {
// We won't be able to delete or modify our message if we send it too \
fast, so better play safe. tongueTurns *= 2;
}
// Let our deep thinking thread do its magic while we're eating, \
showering, training, commuting, etc. thought.ponderForHours(tongueTurns);
wait(); // It may take some more time before HumanEmulation wakes us up \
if we're busy or not feeling good.
Array<Message> repliesFromOthers = incoming.getReplies();
if (! skeleton.worthWriting(repliesFromOthers)) {
throw new Exception("We're exceptionally smart; we managed to let \
someone else do the job!"); Life.enjoy();
if (Life.getFreeTime()) {
/* If we saved so much time that we're now feeling guilty about \
having some free time, use it to attract new recruits in our team.
This should be easier now that our team has quality communication
and looks like a growth opportunity for prospects,
rather than an immature and overwork-frustrated crew. */
recruitNewColleagues();
}
Feeling.stress--;
System.exit(Feeling.HAPPY);
}
incoming.read(); // WARNING: moving this out of the loop will NOT \
optimize!
/* To be truly evil, if others already made some of our points, remember \
to thank them, to encourage them to keep doing our job in the future! */
// We usually store a reply as a draft in an MUA.
if (latestVersion == null) {
latestVersion = incoming.generateReplyFromIdeas(skeleton, \
repliesFromOthers); } else {
latestVersion.readCarefully();
/* If the sender discussed a valid problem and it's necessary to \
discuss timeframes, we can use this opportunity to try enticing them to help
mentioning that more *skilled* manpower would speed up. */
latestVersion = incoming.reviewReply(latestVersion, \
repliesFromOthers); }
} while (previousVersion == null || ! Judgment.areSimilar(previousVersion, \
latestVersion)); Message reply = latestVersion;
if (reply.getValueToReaders() < reply.getCostToRead()) {
System.out.println("Aborting due to negative net value");
System.exit(1);
}
/* We ended up having to reply anyway, but at least, if others replied first,
we have less to write, and we let them do some research and practice their \
writing skills, so we get left with even less on our plate next time.
And the best part is that with all these tongue turns, we're more likely \
replying during the weekend,
which means it's more likely recipients will read us on a weekend and will \
have a cooler reaction, even if they're lacking FingerSaver! */
reply.send();
/* If we're lucky, our reply was exhaustive and boring.
We won't need to answer follow-up questions or clarify/justify what we \
wrote. So we shouldn't be back here for a while, but play safe. */
sleep(A_BIT);
/* Wow, we managed to write an incredibly insightful reply,
which makes us look much more brilliant than the stupid program we're using!
With all the time we saved, we can integrate the people who will volunteer \
to help us.
And in case these take some time to show up, while they're digesting the \
full extent of our genius,
we can validate that our issue tracker properly reflects our load level,
and if it's really urgent, call for help. */
Feeling.stress--; // We won't have to defend having said something stupid.
/* We're bad judges of our own emotivity, but we can at least see how much we \
improved to estimate the minimum emotivity we were under. */
Float climateChangeReductionFactor =
Judgment.getFlammability(initialVersion) / \
Judgment.getFlammability(latestVersion);
/* In case our initial reaction turned out excessively inflammatory,
adjust our system's balance between longevity and performance. */
System.throttleByFactor(climateChangeReductionFactor);
}
}
// TODO: Expand to help truly healing from burnout. At this point, this only aims to \
help with overwork.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic