Formal request to set up a KDE Discourse instance
Philippe Cloutier
chealer at gmail.com
Sun Feb 28 19:32:03 GMT 2021
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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20210228/18b1c3f1/attachment.htm>
-------------- next part --------------
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.
More information about the kde-community
mailing list