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 <[email protected]>
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
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.
