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:
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.
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: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! :) NateMay 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?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- Philippe Cloutier http://www.philippecloutier.com