[heroes] Someone please make an English version of this
https://es.opensuse.org/SDB:NVIDIA_Optimus I'm having no luck figuring out the translator pages with gray on gray text, or interpreting their worthless tiny icons. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Felix Miata composed on 2021-03-08 00:27 (UTC-0500):
https://es.opensuse.org/SDB:NVIDIA_Optimus I'm having no luck figuring out the translator pages with gray on gray text, or interpreting their worthless tiny icons.
Having to send people to https://wiki.archlinux.org/index.php/NVIDIA_Optimus is uncool. :P -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 08/03/2021 06.46, Felix Miata wrote:
Felix Miata composed on 2021-03-08 00:27 (UTC-0500):
https://es.opensuse.org/SDB:NVIDIA_Optimus I'm having no luck figuring out the translator pages with gray on gray text, or interpreting their worthless tiny icons.
Having to send people to https://wiki.archlinux.org/index.php/NVIDIA_Optimus is uncool. :P
There is now https://en.opensuse.org/SDB:NVIDIA_Optimus redirecting to the preexisting page. We can still create a DNS record archwiki.opensuse.org CNAME wiki.archlinux.org. :-P
Bernhard M. Wiedemann composed on 2021-03-08 07:06 (UTC+0100):
Felix Miata wrote:
Felix Miata composed on 2021-03-08 00:27 (UTC-0500):
https://es.opensuse.org/SDB:NVIDIA_Optimus I'm having no luck figuring out the translator pages with gray on gray text, or interpreting their worthless tiny icons.
Having to send people to https://wiki.archlinux.org/index.php/NVIDIA_Optimus is uncool. :P
There is now https://en.opensuse.org/SDB:NVIDIA_Optimus redirecting to the preexisting page.
That should be just as good. :)
We can still create a DNS record archwiki.opensuse.org CNAME wiki.archlinux.org.
What will that accomplish? -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 08/03/2021 08.46, Felix Miata wrote:
Bernhard M. Wiedemann composed on 2021-03-08 07:06 (UTC+0100):
Felix Miata wrote:
...
We can still create a DNS record archwiki.opensuse.org CNAME wiki.archlinux.org.
:-P
What will that accomplish?
Do you want a cup of coffee? Tea? With milk? :-DD -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. composed on 2021-03-08 12:31 (UTC+0100):
Felix Miata wrote:
Bernhard M. Wiedemann composed on 2021-03-08 07:06 (UTC+0100):
We can still create a DNS record archwiki.opensuse.org CNAME wiki.archlinux.org.
What will that accomplish?
Do you want a cup of coffee? Tea? With milk? :-DD
???????????????.??? -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 08/03/2021 14.13, Felix Miata wrote:
Carlos E. R. composed on 2021-03-08 12:31 (UTC+0100):
Felix Miata wrote:
Bernhard M. Wiedemann composed on 2021-03-08 07:06 (UTC+0100):
We can still create a DNS record archwiki.opensuse.org CNAME wiki.archlinux.org.
What will that accomplish?
Do you want a cup of coffee? Tea? With milk? :-DD
???????????????.???
You need more coffee to catch the humour in what Bernhard wrote :-D -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 08/03/2021 06.27, Felix Miata wrote:
https://es.opensuse.org/SDB:NVIDIA_Optimus I'm having no luck figuring out the translator pages with gray on gray text, or interpreting their worthless tiny icons.
No <https://en.opensuse.org/SDB:NVIDIA_Optimus>? Apparently, the translation is <https://en.opensuse.org/SDB:NVIDIA_Bumblebee> There is a menu above that reads "En otros idiomas" (in other languages) that offers English. And that English version is about one year more recent (2019). If you still want to a translation, I can make one for you using DeepL site (plain text only). But this is the wrong mail list, wiki writers and translators do not lurk here. Different jobs. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
We don't need to translate this document at all. Instead there is the better: - https://opensuse.github.io/openSUSE-docs-revamped/install_proprietary/ - https://opensuse.github.io/openSUSE-docs-revamped/hybrid_graphics/ That will probably replace the wikis as the main source of up-to-date and best-practice documentation. The more is fed to the wikis in the mean time, the more work it creates for maintainers.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2021-03-14 at 16:16 -0000, Adrien Glauser wrote:
We don't need to translate this document at all. Instead there is the better: - https://opensuse.github.io/openSUSE-docs-revamped/install_proprietary/ - https://opensuse.github.io/openSUSE-docs-revamped/hybrid_graphics/
That will probably replace the wikis as the main source of up-to-date and best-practice documentation. The more is fed to the wikis in the mean time, the more work it creates for maintainers.
I see two caveats. Users search the wiki, not github, and users also don't write on github. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHYEARECADYWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYE5dxhgcY2FybG9zLmUu ckBvcGVuc3VzZS5vcmcACgkQtTMYHG2NR9UYJQCfaeORsgcm4/TTXDU4uQcEknez EpMAn0lzoYmzAXrj8DbAgkVVZoHsN0wJ =y3eP -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday, 2021-03-14 at 16:16 -0000, Adrien Glauser wrote:
We don't need to translate this document at all. Instead there is the better: -
https://opensuse.github.io/openSUSE-docs-revamped/install_proprietary/
- https://opensuse.github.io/openSUSE-docs-revamped/hybrid_graphics/
That will probably replace the wikis as the main source of up-to-date and best-practice documentation. The more is fed to the wikis in the mean time, the more work it creates for maintainers.
I see two caveats. Users search the wiki, not github, and users also don't write on github.
+2 -- Per Jessen, Zürich (3.6°C) Member, openSUSE Heroes
Per Jessen composed on 2021-03-14 21:38 (UTC+0100):
Carlos E. R. wrote:
On Sunday, 2021-03-14 at 16:16 -0000, Adrien Glauser wrote:
We don't need to translate this document at all. Instead there is the better: -
https://opensuse.github.io/openSUSE-docs-revamped/install_proprietary/ - https://opensuse.github.io/openSUSE-docs-revamped/hybrid_graphics/
That will probably replace the wikis as the main source of up-to-date and best-practice documentation. The more is fed to the wikis in the mean time, the more work it creates for maintainers.
I see two caveats. Users search the wiki, not github, and users also don't write on github.
+2
+3 When I'm searching, I'm usually including this specification: site:opensuse.org Github.io pages won't be found. Simply including opensuse as a search term typically produces woeful results. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Somehow my first paragraph didn't make it to the spell checker, my apology. 8<--------------------------------------------------------------- There are some caveats, but those you mention are not among them. The wikis as a humongous heap of outdated information tightly interlocked with excellent and up-to-date information, and way too few maintainers to cover all blind spots. This means that the new user has 0 possibility of untangling one from the other, or of finding someone to do that for them. In other words: the wikis should *not* in any way be used as a stable repository of technical and critical information. They should *only* be used to record ongoing activities and short-term information. We with the docs team are working our a** off to provide the community with decent docs ASAP, so if someone sends new users to the thing that needs to be removed because it creates a competing -- no matter how inferior -- "source of truth", or otherwise make it grow even bigger, that person is making our work twice as difficult: not only are we going to have to clean an even bigger mess, but also we will have to change the user's mindset, to make sure they stop considering the wikis as a reliable source of truth. I hope you do understand.
There are some caveats, who those you mention are not among them. The wikis as a humongus heap of outdated information tightly interlocked with excellent and up-to-date information, a way too few maintainers to cover all blind spots. This means that the new user has 0 possibility of untangling one from the other, and of finding someone to do that for them. In other words: the wikis should *not* in any way be used as a stable repository of technical and critical information. They should *only* be used to record ongoing activities and short-term information. We with the docs team are working our a** off to provide the community with decent docs ASAP, so if someone sends new users to the thing that needs to be removed because it creates a competing -- no matter how inferior -- "source of truth", or otherwise make it grow even bigger, that person is making our work twice as difficult: not only are we going to have to clean an even bigger mess, but also we will have to change the user's mindset, to make sure they stop considering the wikis as a reliable source of truth. I hope you do understand.
On 14/03/2021 22.51, Adrien Glauser wrote:
There are some caveats, who those you mention are not among them. The wikis as a humongus heap of outdated information tightly interlocked with excellent and up-to-date information, a way too few maintainers to cover all blind spots. This means that the new user has 0 possibility of untangling one from the other, and of finding someone to do that for them. In other words: the wikis should *not* in any way be used as a stable repository of technical and critical information. They should *only* be used to record ongoing activities and short-term information.
We with the docs team are working our a** off to provide the community with decent docs ASAP, so if someone sends new users to the thing that needs to be removed because it creates a competing -- no matter how inferior -- "source of truth", or otherwise make it grow even bigger, that person is making our work twice as difficult: not only are we going to have to clean an even bigger mess, but also we will have to change the user's mindset, to make sure they stop considering the wikis as a reliable source of truth.
I hope you do understand.
Then you will have to work on putting that under opensuse.org web structure somewhere. On gitthub the large user base will not find them. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Absolutely. GitHub is where we work. The better it gets, the closer to the end user it will move.
On 14/03/2021 23.47, Adrien Glauser wrote:
Absolutely. GitHub is where we work. The better it gets, the closer to the end user it will move.
https://doc.opensuse.org/ seems like an appropriate place. I hope it can be integrated with the existing structure. The first thought I have is that you create extra work by not using the wiki because the wiki allows easy editing+updating of information for users. It is just unorganized. I bet, we could use more of those "tested with Leap 15.2" tags or auto-flag/hide pages that were not updated for 3 years. OTOH github allows web-edits these days to create PRs, thus not so much harder. It just needs someone to review. And you will also get outdated information in there soon, so it still needs some way to handle that, wiki or not.
On 15/03/2021 05.44, Bernhard M. Wiedemann wrote:
On 14/03/2021 23.47, Adrien Glauser wrote:
Absolutely. GitHub is where we work. The better it gets, the closer to the end user it will move.
https://doc.opensuse.org/ seems like an appropriate place. I hope it can be integrated with the existing structure.
The first thought I have is that you create extra work by not using the wiki because the wiki allows easy editing+updating of information for users.
It is just unorganized. I bet, we could use more of those "tested with Leap 15.2" tags or auto-flag/hide pages that were not updated for 3 years.
OTOH github allows web-edits these days to create PRs, thus not so much harder. It just needs someone to review. And you will also get outdated information in there soon, so it still needs some way to handle that, wiki or not.
With the added problem that plain users can not update github, while we can update the wiki. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 3/15/21 6:32 PM, Carlos E. R. wrote:
On 15/03/2021 05.44, Bernhard M. Wiedemann wrote:
On 14/03/2021 23.47, Adrien Glauser wrote:
Absolutely. GitHub is where we work. The better it gets, the closer to the end user it will move.
https://doc.opensuse.org/ seems like an appropriate place. I hope it can be integrated with the existing structure.
The first thought I have is that you create extra work by not using the wiki because the wiki allows easy editing+updating of information for users.
It is just unorganized. I bet, we could use more of those "tested with Leap 15.2" tags or auto-flag/hide pages that were not updated for 3 years.
OTOH github allows web-edits these days to create PRs, thus not so much harder. It just needs someone to review. And you will also get outdated information in there soon, so it still needs some way to handle that, wiki or not.
With the added problem that plain users can not update github, while we can update the wiki.
Carlos you should find it no harder to update docs on github then the wiki, these days with the in built editor its basically the same process, github might even be easier :-) -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Am March 15, 2021 8:54:22 AM UTC schrieb Simon Lees <sflees@suse.de>:
Carlos you should find it no harder to update docs on github then the wiki, these days with the in built editor its basically the same process, github might even be easier :-)
* Is there a step-by-step tutorial? * Can I do it with my openSUSE account? Regards, Lars
On Mo, Mär 15, 2021 at 09:53, Lars Vogdt <lars@linux-schulserver.de> wrote:
* Is there a step-by-step tutorial? * Can I do it with my openSUSE account?
Well, I have some good news for you, I was planning to migrate all of our jekyll websites to code.opensuse.org, so both of those will be yes. We just need a Jenkins CI server, because I don't really want to have websites miss out on being tested. LCP [Sasi] https://lcp.world
Am Mon, 15 Mar 2021 12:48:20 +0100 schrieb Sasi Olin <hellcp@opensuse.org>:
Well, I have some good news for you, I was planning to migrate all of our jekyll websites to code.opensuse.org, so both of those will be yes. We just need a Jenkins CI server, because I don't really want to have websites miss out on being tested.
Very nice! But this - obviously - brings up the questions why the heroes need to run (the currently internal) Gitlab and Pagure in parallel ? Can't we agree on one tool and drop the other one? With kind regards, Lars
On Mo, Mär 15, 2021 at 13:35, Lars Vogdt <lars@linux-schulserver.de> wrote:
Very nice! But this - obviously - brings up the questions why the heroes need to run (the currently internal) Gitlab and Pagure in parallel ?
Can't we agree on one tool and drop the other one?
Don't you worry, Jenkins server blocks that too, when we have that resolved I hope we move everything to pagure. LCP [Sasi] https://lcp.world
Am Mon, 15 Mar 2021 13:37:04 +0100 schrieb Sasi Olin <hellcp@opensuse.org>:
But this - obviously - brings up the questions why the heroes need to run (the currently internal) Gitlab and Pagure in parallel ?
Can't we agree on one tool and drop the other one?
Don't you worry, Jenkins server blocks that too, when we have that resolved I hope we move everything to pagure.
Well, I don't know Pagure, but our Gitlab already supports Gitlab-Runners. There is also ci.opensuse.org - a Jenkins instance that might be used...? I really would love to see us doing more consolidation of tools instead inventing/implementing more and more and more - without keeping in mind that these tools need to be maintained somehow. Regards, Lars
On Mo, Mär 15, 2021 at 14:14, Lars Vogdt <lars@linux-schulserver.de> wrote:
Well, I don't know Pagure, but our Gitlab already supports Gitlab-Runners. There is also ci.opensuse.org - a Jenkins instance that might be used...?
We asked, that's apparently SUSE only
I really would love to see us doing more consolidation of tools instead inventing/implementing more and more and more - without keeping in mind that these tools need to be maintained somehow.
Pagure is *supposed to* replace both gitlab and progress, we will see how that goes ;) LCP [Sasi] https://lcp.world
Am Mon, 15 Mar 2021 15:17:50 +0100 schrieb Sasi Olin <hellcp@opensuse.org>:
Well, I don't know Pagure, but our Gitlab already supports Gitlab-Runners. There is also ci.opensuse.org - a Jenkins instance that might be used...?
We asked, that's apparently SUSE only
I guess you refer to ci.opensuse.org, right? If that's the case, we might consider to discuss this with the involved parties. Otherwise it looks to me like we invent (and maintain) everything twice in the long run.
Pagure is *supposed to* replace both gitlab and progress, we will see how that goes ;)
I know that the following is kind of unfair, so please don't take it as affront: * Are the maintainers of Gitlab and Progress aware of this? * Is there a migration planned? * Is there a timeline that people can rely on? Again: no affront here, but I also like to see how much time we should invest in - for example - upgrading Redmine (Progress) or work on making Gitlab (especially the runners) better. If people know that the plan is to obsolete Gitlab and Progress, maybe they can join other areas. Suggested other areas (just out of nowhere): * Wiki.o.o upgrade * integrating mlmmj archives in mailman 3 * upgrading Elections.o.o * prepare failover setups (next NUE downtime... ;-) * cleanup tickets on progress.o.o I just want to avoid that we waste someones spare time to work on things that are planned to get obsolete... Regards, Lars
Lars Vogdt wrote:
* integrating mlmmj archives in mailman 3
I think we're good on that one, except for the index. I cannot believe how slow that combination of python+xapian is. My most recent attempt got killed again.
I just want to avoid that we waste someones spare time to work on things that are planned to get obsolete...
There is also the old saying "if it aint broke ...." -- Per Jessen, Zürich (6.3°C) Member, openSUSE Heroes
Am Mon, 15 Mar 2021 15:49:12 +0100 schrieb Per Jessen <per@opensuse.org>:
* integrating mlmmj archives in mailman 3
I think we're good on that one, except for the index. I cannot believe how slow that combination of python+xapian is. My most recent attempt got killed again.
I haven't looked at it, but IMHO without Index no Search, right? Is there any way to speed up the stuff? Maybe by indexing in chunks? Are there any Fedora admins that can help here? Regards, Lars
Lars Vogdt wrote:
Am Mon, 15 Mar 2021 15:49:12 +0100 schrieb Per Jessen <per@opensuse.org>:
* integrating mlmmj archives in mailman 3
I think we're good on that one, except for the index. I cannot believe how slow that combination of python+xapian is. My most recent attempt got killed again.
I haven't looked at it, but IMHO without Index no Search, right?
Correct - at worst we get incomplete search results. Don't worry, my problem, not yours :-)
Is there any way to speed up the stuff? Maybe by indexing in chunks?
No idea :-( -- Per Jessen, Zürich (3.9°C) Member, openSUSE Heroes
On Mo, Mär 15, 2021 at 15:33, Lars Vogdt <lars@linux-schulserver.de> wrote:
I guess you refer to ci.opensuse.org, right? If that's the case, we might consider to discuss this with the involved parties. Otherwise it looks to me like we invent (and maintain) everything twice in the long run.
Neal I think already reached out asking for it to be opened up for openSUSE, so deferring to him :P
I know that the following is kind of unfair, so please don't take it as affront: * Are the maintainers of Gitlab and Progress aware of this?
Progress yes, we only discussed Gitlab in passing, so there I'm not sure
* Is there a migration planned?
No
* Is there a timeline that people can rely on?
Until we have CI, we can't migrate most things, while others are already being migrated. Timeline would require us to have a solid idea of when CI will be set up though.
Again: no affront here, but I also like to see how much time we should invest in - for example - upgrading Redmine (Progress) or work on making Gitlab (especially the runners) better.
If people know that the plan is to obsolete Gitlab and Progress, maybe they can join other areas.
Of course the problem being, we didn't really create issues for migration, so nobody knows what to actually do. Probably a mistake on our side.
Suggested other areas (just out of nowhere): * Wiki.o.o upgrade * integrating mlmmj archives in mailman 3 * upgrading Elections.o.o * prepare failover setups (next NUE downtime... ;-) * cleanup tickets on progress.o.o
I just want to avoid that we waste someones spare time to work on things that are planned to get obsolete...
That's totally understandable LCP [Sasi] https://lcp.world
Am Mon, 15 Mar 2021 18:07:59 +0100 schrieb Sasi Olin <hellcp@opensuse.org>:
* Are the maintainers of Gitlab and Progress aware of this?
Progress yes, we only discussed Gitlab in passing, so there I'm not sure
Gitlab is mainly internal only because we were not sure in the beginning if we might end up storing passwords in Salt (and therefor the git repository of Salt). Right now we use "pass" to store GPG encrypted passwords and Gitlab's permissions only allow members of the right group to see them or check them out. I'm not 100% sure if we really want to provide another "code hosting" platform without a real need - but (just in case) maybe we can also consider to make Gitlab public? Or is it already set in stone that openSUSE is using Pagure now? In that case, I would love to see us getting rid of Gitlab. But I don't know Pagure good enough to finally make this decision. Is there any difference between Gitlab and Pagure?
* Is there a migration planned?
No
Really? If this means manual work/migration, this would be a blocker for me. Gitlab -> Pagure might not be that problematic, but at least for Redmine, this would be a no-go.
* Is there a timeline that people can rely on?
Until we have CI, we can't migrate most things, while others are already being migrated. Timeline would require us to have a solid idea of when CI will be set up though.
Well: firing up a Jenkins installation is not really rocket science. ;-) But: maintaining it and keeping it secure is a completely different story, I agree.
Of course the problem being, we didn't really create issues for migration, so nobody knows what to actually do. Probably a mistake on our side.
Not a big deal. Can I ask you to create some issues for the stuff on your agenda? - Looks like at least I lost track of it.
Suggested other areas (just out of nowhere): * Wiki.o.o upgrade * integrating mlmmj archives in mailman 3 * upgrading Elections.o.o * prepare failover setups (next NUE downtime... ;-) * cleanup tickets on progress.o.o
I just want to avoid that we waste someones spare time to work on things that are planned to get obsolete...
That's totally understandable
Jip, especially as I'm still waiting for: * new FreeIPA (#64162 ?, #88433) * new DNS, incl. easy management GUI (#88433) * fixing tsp (#89647) * 100% reliable Matrix (#63463, #88279, #88497, ...) * forums migration to discourse (#88433) * re-enabling nntp for forums (#47015) * finalizing mailman 3 migration (#19900, #80900, ...) * deprecation of community.o.o (#70264, #63466) * replacement of account system (#64159) * handling meet.o.o problems (#89575, #66173) * adding a calendar for openSUSE events (#88457) * setting up BigBlueButton (#75268) * adjusting login.template (#68512) * fixing susepaste (#56189) * fixing survey.o.o (#80454) * fixing osc-collab (#69568) * fixing news.o.o (#67222) * fixing Weblate auth (#89857, #73411, #69424) * updating MediaWiki (#61104) * updating ElasticSearch (#62672) * migration of openSUSE domains (#88433, #88520) * enabling DCIM and DNSSec (#88433 + boo#690867) * Scripts to delete/disable users as requested by GDPR * additional documentation and training material * someone fixing the remaining *285* open Redmine issues * ... Sorry to sound a bit unfair, but I have to admit that I am surprised that there are currently so many new (interesting) fields of action, while we still lack the manpower to work on all the existing problems. I know that working on that "old, rotten stuff" is not always so much fun and often enough even nerve-wracking, but this is what makes people think the openSUSE heroes are non-functional/not-productive, as they are not even able to handle their (community/user) issues in a timely manner. Couldn't we agree to solve at least some of the problems listed above, first, before you start turning the openSUSE infrastructure inside out? With kind regards, Lars
On 15/03/2021 22.01, Lars Vogdt wrote:
Am Mon, 15 Mar 2021 18:07:59 +0100 schrieb Sasi Olin <hellcp@opensuse.org>:
...
Suggested other areas (just out of nowhere): * Wiki.o.o upgrade * integrating mlmmj archives in mailman 3 * upgrading Elections.o.o * prepare failover setups (next NUE downtime... ;-) * cleanup tickets on progress.o.o
I just want to avoid that we waste someones spare time to work on things that are planned to get obsolete...
That's totally understandable
Jip, especially as I'm still waiting for: * new FreeIPA (#64162 ?, #88433) * new DNS, incl. easy management GUI (#88433) * fixing tsp (#89647) * 100% reliable Matrix (#63463, #88279, #88497, ...) * forums migration to discourse (#88433) * re-enabling nntp for forums (#47015)
There is an nntp server, not connected to the forums, but if the forum engine is going to be migrated, there is no point on working on the connection yet. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. wrote:
* re-enabling nntp for forums (#47015)
There is an nntp server, not connected to the forums, but if the forum engine is going to be migrated,
For the time being, there are no practical plans - Olav has upgraded vBulletin to latest and greatest, except in production. (his test installation is looking great btw). Any chance of hooking up an nntp service would be progress. -- Per Jessen, Zürich (4.5°C) Member, openSUSE Heroes
On 15/03/2021 22.29, Per Jessen wrote:
Carlos E. R. wrote:
* re-enabling nntp for forums (#47015)
There is an nntp server, not connected to the forums, but if the forum engine is going to be migrated,
For the time being, there are no practical plans - Olav has upgraded vBulletin to latest and greatest, except in production. (his test installation is looking great btw). Any chance of hooking up an nntp service would be progress.
What's the point, if it is going to be migrated to discourse? It would be effort lost. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. wrote:
On 15/03/2021 22.29, Per Jessen wrote:
Carlos E. R. wrote:
* re-enabling nntp for forums (#47015)
There is an nntp server, not connected to the forums, but if the forum engine is going to be migrated,
For the time being, there are no practical plans - Olav has upgraded vBulletin to latest and greatest, except in production. (his test installation is looking great btw). Any chance of hooking up an nntp service would be progress.
What's the point, if it is going to be migrated to discourse? It would be effort lost.
Not at all - the nntp setup can be re-used with discourse. -- Per Jessen, Zürich (9.1°C) Member, openSUSE Heroes
Bernhard M. Wiedemann wrote:
On 14/03/2021 23.47, Adrien Glauser wrote:
Absolutely. GitHub is where we work. The better it gets, the closer to the end user it will move.
https://doc.opensuse.org/ seems like an appropriate place. I hope it can be integrated with the existing structure.
The first thought I have is that you create extra work by not using the wiki because the wiki allows easy editing+updating of information for users.
That was also my first thought. That does seem to be a key issue. We have to involve the users, not alienate them. -- Per Jessen, Zürich (3.8°C) Member, openSUSE Heroes
No, that is not a key issue at all, as long as you provide simple and user-friendly guidelines for contributing in general, and to github in particular. I repeat, there is no future for technical and critical information on "user-friendly" CMS. CMS cannot solve the "when a drop of outdated, factually incorrect, or recommended against information is mixed to bucket of information, no matter how good, all the information in the bucket becomes unreliable" issue. The only way to properly ground the chain of trust in facts and best-practices is by having maintainers and reviewers work hand-in-hand and jointly educate the next generation of maintainers and reviewers, and so on and so forth.
If I may add: this surely does not mean that there is no role for the wikis to play. That role is simply not displaying technical and critical information. It's something most the other distros have understood (Debian, Fedora, Ubuntu, NixOS). They keep using wikis but mainly for community things.
doc.opensuse.org is the place GitHub is our workplace. We happen to serve the docs there, for demo purposes and also to be able to link people to specific sections, when they are in good shape. Of course you're right that it should be hosted in a appropriate place, and docs.opensuse.org might be the one. Not putting the docs under the spotlight was obvious, because it's a construction site, but the better it gets the more it deserves to be considered.
extra work for not using the wikis I for one never said the wikis ought not to be used. On the contrary, we need to void the wikis of the best infos they provide and move it to a proper doc platform. Consider in that regard: https://etherpad.opensuse.org/p/wiki-pages-reporting
outdated information We're moving on from the wikis "hit-and-run" contribution model to a maintainer-centric contribution model, in which the docs is, like any other source code, reviewed and updated over time. I warmly invite you to come say Hi and see for yourself :)
All in all it's just like for every transition period: there will be a grey area where some wiki pages are not bad enough and our docs not good enough to convince people to move to our docs. It's part of the journey. The more you guys help, for instance on recommending and contributing to the new docs, the faster we'll arrive at destination.
participants (9)
-
Adrien Glauser -
Bernhard M. Wiedemann -
Carlos E. R. -
Carlos E. R. -
Felix Miata -
Lars Vogdt -
Per Jessen -
Sasi Olin -
Simon Lees