From Newsgroup: news.admin.hierarchies

Following an old thread from July 2021:

In the thread "Survey about microsoft.* newsgroups" in microsoft.public.windowsxp.general (<news:sbi7j3$r53$1@news.trigofacile.com>), 4 persons answered.

Basically, they do not see any point in creating new newsgroups in microsoft.* because they already have newsgroups in alt.* for new
Microsoft products.
A few legacy newsgroups like the one for Windows XP are still used in
the microsoft.* hierarchy.-a People don't mind reading newsgroups from different hierarchies (alt.*, microsoft.*, comp.*, local ones...) in
their news reader.

Currently, they prefer to go on adding groups in alt.* that suit their needs.

As I will no longer send any control messages for microsoft.*, this
hierarchy can now be advertised as unmanaged. The syncable server msnews.microsoft.com, contact, URL and key information can be removed
from control.ctl.
The comment could be changed to say that the current list of newsgroups reflect the ones present in msnews.microsoft.com in May 2010. Then
Microsoft began closing newsgroups and migrating users to Microsoft
forums that include Microsoft Answers, TechNet and MSDN. Their news
server was discontinued in October 2010.

Note to Jason:-a they spoke about the difficulty to add groups to comp.*
(a hierarchy which would otherwise have been likely to be used to
discuss current Microsoft products).-a There are still Windows 95
newsgroups in comp.*; hope the new Big Eight board will give more
freshness to the hierarchy.

I still reckon that if new newsgroups for Microsoft products are wished,
the comp.* hierarchy is a suitable one (besides of course alt.* where
recent newsgroups exist for latest Windows 11).

Instead of Windows 95 newsgroups still present in comp.*, a more generic
one could be useful for Windows and maybe another generic one for
Microsoft 365 products...
--
Julien |eLIE

-2-aLe carr|- est un triangle qui a r|-ussi, ou une circonf|-rence qui a mal
tourn|-.-a-+ (Pierre Dac)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien +LIE wrote:

Note to Jason:a they spoke about the difficulty to add groups to comp.*
(a hierarchy which would otherwise have been likely to be used to
discuss current Microsoft products).a There are still Windows 95
newsgroups in comp.*; hope the new Big Eight board will give more
freshness to the hierarchy.

I still reckon that if new newsgroups for Microsoft products are wished,
the comp.* hierarchy is a suitable one (besides of course alt.* where
recent newsgroups exist for latest Windows 11).

That would be appropriate, yes. Back in 2010, some people made a list with replacements for the 129 German language groups in microsoft.public.de.*
[1]; most of the active groups already had a (mostly) matching newsgroup
in de.*, and some missing ones were created (or moved), i.e. for
VisualBasic and MS Office components.

Instead of Windows 95 newsgroups still present in comp.*, a more generic
one could be useful for Windows and maybe another generic one for
Microsoft 365 products...

Yep.

-thh
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

Following an old thread from July 2021:

In the thread "Survey about microsoft.* newsgroups" in >>microsoft.public.windowsxp.general >>(<news:sbi7j3$r53$1@news.trigofacile.com>), 4 persons answered.

Basically, they do not see any point in creating new newsgroups in >>microsoft.* because they already have newsgroups in alt.* for new >>Microsoft products.
A few legacy newsgroups like the one for Windows XP are still used in
the microsoft.* hierarchy.a People don't mind reading newsgroups from >>different hierarchies (alt.*, microsoft.*, comp.*, local ones...) in
their news reader.

Currently, they prefer to go on adding groups in alt.* that suit their >>needs.

As I will no longer send any control messages for microsoft.*, this >hierarchy can now be advertised as unmanaged.

I'm making the same comment here as I made in the other thread. Please
do not categorize it as "unmanaged". It's a former institutional
hierarchy. There should be no automatic processing of control messages.

In an administered hierarchy, the hierarchy administrator sends the
newgroup message on behalf of the proponent. In an unadministered
hierarchy, the proponent sends the newgroup message himself.

In a former institutional hierarchy, there can be no proponents. If the institution itself isn't out of business and wants to resume
administering the hierarchy itself (which has never happened), that
would be acceptable. But unless that happens, just leave the newsgroups
as they were before the decision was made to stop maintaining
newsgroups. No one at all should issue control messages.

. . .

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Hi Adam,

I'm making the same comment here as I made in the other thread. Please
do not categorize it as "unmanaged". It's a former institutional
hierarchy. There should be no automatic processing of control messages.

"Unmanaged" means there's no longer a control.ctl entry for that
hierarchy. The default one for control.ctl applies:

## Default (for any group)
newgroup:*:*:mail
rmgroup:*:*:mail

The list of microsoft.* newsgroups still remains in the active and
newsgroups file in ftp.isc.org.


As I suggested to keep a comment, I agree "unmanaged" is not the right
term. Maybe the term "historic" is better?
http://usenet.trigofacile.com/hierarchies/index.py?status=historic

Like un.* which has the following entry, but for microsoft.* we no
longer need the PGP entries, but just keep the first 2 drop lines.

## UN (*HISTORIC* -- The United Nations)
#
# This hierarchy is not entirely defunct, but it receives very little
# traffic and is included primarily for the sake of completeness.
#
# Admin group: un.public.usenet.admin
# *PGP* See comment at top of file.
newgroup:*:un.*:drop
rmgroup:*:un.*:drop checkgroups:news@news.itu.int:un.*:verify-ungroups@news.itu.int newgroup:news@news.itu.int:un.*:verify-ungroups@news.itu.int rmgroup:news@news.itu.int:un.*:verify-ungroups@news.itu.int
--
Julien |eLIE

-2-aLe carr|- est un triangle qui a r|-ussi, ou une circonf|-rence qui a mal
tourn|-.-a-+ (Pierre Dac)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Adam,

I'm making the same comment here as I made in the other thread. Please
do not categorize it as "unmanaged". It's a former institutional
hierarchy. There should be no automatic processing of control messages.

"Unmanaged" means there's no longer a control.ctl entry for that
hierarchy.

We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.

The default one for control.ctl applies:

## Default (for any group)
newgroup:*:*:mail
rmgroup:*:*:mail

I forgot about that entry.

The list of microsoft.* newsgroups still remains in the active and >newsgroups file in ftp.isc.org.

As I suggested to keep a comment, I agree "unmanaged" is not the right
term. Maybe the term "historic" is better?
http://usenet.trigofacile.com/hierarchies/index.py?status=historic

You do list a number of DEFUNCT hierarchies in control.ctl.

In the other thread, I nominated the category "former institutional
hierarchy".
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Hi Adam,

I'm making the same comment here as I made in the other thread. Please
do not categorize it as "unmanaged". It's a former institutional
hierarchy. There should be no automatic processing of control messages.

"Unmanaged" means there's no longer a control.ctl entry for that
hierarchy.

We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.

OK, I'll change the "unmanaged" term I used, which was not appropriate.

As I suggested to keep a comment, I agree "unmanaged" is not the right
term. Maybe the term "historic" is better?

In the other thread, I nominated the category "former institutional hierarchy".

All of the following hierarchies are not institutional ones:
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

I'm looking for a better term. Maybe "legacy" or "unreferenced"? (or
calling them "historic" too)

As or microsoft.*, it can fall back in the existing "historic" category.
--
Julien |eLIE

-2-aPour une personne optimiste, le verre est |a moiti|- plein. Pour une
personne pessimiste, il est |a moiti|- vide. Pour l'informaticien, il
est deux fois plus grand que n|-cessaire.-a-+
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien LIE <iulius@nom-de-mon-site.com.invalid> wrote:

I'm making the same comment here as I made in the other thread. Please >>>>do not categorize it as "unmanaged". It's a former institutional >>>>hierarchy. There should be no automatic processing of control messages.

"Unmanaged" means there's no longer a control.ctl entry for that >>>hierarchy.

We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.

OK, I'll change the "unmanaged" term I used, which was not appropriate.

As I suggested to keep a comment, I agree "unmanaged" is not the right >>>term. Maybe the term "historic" is better?

In the other thread, I nominated the category "former institutional >>hierarchy".

All of the following hierarchies are not institutional ones:
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

Goodness. That's a long list. Yes I see former regional hierarchies in there.

I'm looking for a better term. Maybe "legacy" or "unreferenced"? (or >calling them "historic" too)

As or microsoft.*, it can fall back in the existing "historic" category.

If you don't like "former", then "historic" is better than "legacy". I
don't care for "unreferenced" given that you are making a reference.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Hi Adam,

We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.

I've at last reorganized the listing, following our previous discussion.
Only alt.* and free.* are now in the unmanaged page. The previously
listed ones were now in the historic section.

http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged
--
Julien |eLIE

-2-aPowerPoint allows speakers to pretend that they are giving a real
talk, and audiences to pretend that they are listening.-a-+ (Edward R.
Tufte, _The Cognitive Style of PowerPoint_)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Adam,

We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.

I've at last reorganized the listing, following our previous discussion.
Only alt.* and free.* are now in the unmanaged page. The previously
listed ones were now in the historic section.

http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

That's reasonable. Thank you

I don't have any new comments about the categories that you haven't
heard me make in the past.

Shouldn't mod.* be a reserved hierarchy? I was going to ask about net.*
as well, but you listed it as historic.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Hi Adam,

I've at last reorganized the listing, following our previous discussion.
Only alt.* and free.* are now in the unmanaged page. The previously
listed ones were now in the historic section.

http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

That's reasonable. Thank you

Thanks for having had a look.

I don't have any new comments about the categories that you haven't
heard me make in the past.

Yes, sure, I remember. The point is that these web pages are a visual representation of the control.ctl / PGPKEYS / newsgroups files. Changes should be made upstream.

Shouldn't mod.* be a reserved hierarchy? I was going to ask about net.*
as well, but you listed it as historic.

For example, if mod.* should be listed as reserved (which it could, like example.*, general.* or test.*), the change to do is in the following file:
https://github.com/rra/control-archive/blob/master/config/mod
"type: defunct" should be changed to "type: reserved"

Incidentally, I see in
https://github.com/rra/control-archive/blob/master/forms/control.ctl.pre

that example.*, local.* and private.* (other already reserved groups)
could also be added to this special entry:

## Special reserved groups
newgroup:*:control|general|junk|test|to:drop rmgroup:*:control|general|junk|test|to:drop




If you already have a list of such changes to do, you may want to put it
into an issue in https://github.com/rra/control-archive/issues
When Russ has a bit of time for that, it will facilitate the integration instead of digging in threads in this newsgroup.
(Or course, a direct pull request with the changed files would be even
better if you happen to know how git works.)


net.* is said to be "a failed experiment which has now been abandoned"
in the comments. Would you have seen it in another category than historic?
As the control.ctl entry is "drop" for newgroup and rmgroup, it is not a "public managed" hierarchy. I previously listed it under "public
unmanaged" but now that only alt.* and free.* are considered to be
unmanaged, I moved all these hierarchies without a control.ctl entry
with an explicit e-mail adress to the "historic" state.
--
Julien |eLIE

-2-aTa remise sur pied lui a fait perdre la t|-te-a!-a-+ (Ast|-rix)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:

it-alt.*
oesterreich.*

Shouldn't mod.* be a reserved hierarchy? I was going to ask about net.*
as well, but you listed it as historic.

For example, if mod.* should be listed as reserved (which it could, like >example.*, general.* or test.*), the change to do is in the following file:
https://github.com/rra/control-archive/blob/master/config/mod
"type: defunct" should be changed to "type: reserved"

Incidentally, I see in
https://github.com/rra/control-archive/blob/master/forms/control.ctl.pre

that example.*, local.* and private.* (other already reserved groups)
could also be added to this special entry:

## Special reserved groups
newgroup:*:control|general|junk|test|to:drop >rmgroup:*:control|general|junk|test|to:drop

If you already have a list of such changes to do, you may want to put it >into an issue in https://github.com/rra/control-archive/issues

Ok. I'll see if I can do that.

When Russ has a bit of time for that, it will facilitate the integration >instead of digging in threads in this newsgroup.
(Or course, a direct pull request with the changed files would be even >better if you happen to know how git works.)

net.* is said to be "a failed experiment which has now been abandoned"
in the comments. Would you have seen it in another category than historic? >As the control.ctl entry is "drop" for newgroup and rmgroup, it is not a >"public managed" hierarchy. I previously listed it under "public
unmanaged" but now that only alt.* and free.* are considered to be >unmanaged, I moved all these hierarchies without a control.ctl entry
with an explicit e-mail adress to the "historic" state.

net.* was of course the pre-Great Renaming top-level hierarchy in B News
days. Usenet II reused the defunct hierarchy because it hadn't been
reserved, but that's not the reason for failure. I suppose leave it
listed as historic but add a note about its pre-Great Renaming use.

mod.* was the B News top-level hierarchy for moderated groups before
things were recoded so that a proto-article could be sent in email to
the moderator in the newsreader.

This hierarchy should definitely be reserved.

fa.* (from ARPANET) were gatewayed mailing lists. I have no idea how
clients worked in B News days, but I'm guessing that you had the same
problem as moderated groups, no way to send the proto-article to the
list posting address with the newsreader.

I'd reserve that too.

I recall fj.* (from Japan), which I think were gated mailing lists as well. Good heavens. It's listed as still active.

I'll write up some notes and send it to github.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Hi Adam,

Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:

it-alt.*
oesterreich.*

Oh indeed, I could especially mark them as "unmanaged" too.
I see there is no newsgroups for these two hierarchies in the
ftp.isc.org newsgroups file though, contrary to alt.* and free.*.

oesterreich.* seems to still be somehow active as their web site was
updated in 2022 :
http://www.tahina.priv.at/~cm/oe/index.en.html

mod.* was the B News top-level hierarchy for moderated groups before
things were recoded so that a proto-article could be sent in email to
the moderator in the newsreader.

fa.* (from ARPANET) were gatewayed mailing lists. I have no idea how
clients worked in B News days, but I'm guessing that you had the same
problem as moderated groups, no way to send the proto-article to the
list posting address with the newsreader.

[...]> I'll write up some notes and send it to github.

These are pretty useful and interesting information.
Worthwhile keeping somewhere. I open a new thread about that.
--
Julien |eLIE

-2-aPassion is inversely proportional to the amount of real information
available.-a-+ (Benford's law)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Hi Adam,

Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:

it-alt.*
oesterreich.*

While looking at making the change in the web pages, I see we did not
speak about other alternative hierarchies.

Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
They both have an associated PGP key but I do not know what is the
policy to create a newsgroup? Is it intended after any demand of
someone and a signed control article is then sent, or is there a
validation by a sort of Board?

no.alt.* has 41 newsgroups listed in ftp.isc.org, nl-alt.* only 3.


And what for de.alt.*? Shouldn't it be considered as "unmanaged"?
If I remember well, there's a possibility to create any newsgroup in
de.alt.* (its control.ctl entry has a doit for a newgroup control
article) and for the sake of not removing them with de.* PGP-signed checkgroups, they are included in de.* checkgroups.
--
Julien |eLIE

-2-aTant qu'il y a des marmites, il y a de l'espoir-a!-a-+ (Ast|-rix)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Adam,

Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:

it-alt.*
oesterreich.*

While looking at making the change in the web pages, I see we did not
speak about other alternative hierarchies.

I had simply noticed it-alt.* and oesterreich.* in rone's unified
control.clt and your generated list. I don't have first hand knowledge.

Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
They both have an associated PGP key but I do not know what is the
policy to create a newsgroup? Is it intended after any demand of
someone and a signed control article is then sent, or is there a
validation by a sort of Board?

no.alt.* has 41 newsgroups listed in ftp.isc.org, nl-alt.* only 3.

I cannot guess what the policies are, but if the control messages
use a PGP key, even if there is some informality about adding a group to checkgroups, I'd call that "managed", given that the proponent would
never send the newgroup message himself. The keyholder has got to be
considered to be the hierarchy manager for this purpose.

This has the advantage that there can be checkgroups issued regularly,
an impossibility in truly unmanaged hierarchies.

And what for de.alt.*? Shouldn't it be considered as "unmanaged"?
If I remember well, there's a possibility to create any newsgroup in >de.alt.* (its control.ctl entry has a doit for a newgroup control
article) and for the sake of not removing them with de.* PGP-signed >checkgroups, they are included in de.* checkgroups.

Is that why no.alt.* control messages are signed as well, because these newsgroups are listed in the checkgroups for no.*?

It seems to me that the hierarchy manager's main job is to list groups
he recognizes in checkgroups, even if there are groups newgrouped in a second-level hierachy with informal procedures.

If there's a checkgroups, that provides satisfactory evidence of
hierarchy management. Similarly, a PGP key provides satisfactory
evidence of hierarchy management.

But if the proponent and not the hierarchy administrator issues newgroup messages in de.alt.* that would never include a PGP key, that requires
a comment.

I would recommend against listing no.alt.*, nl-alt.*, and de.alt.* as unmanaged.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Hi Adam,

Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:

it-alt.*
oesterreich.*

While looking at making the change in the web pages, I see we did not
speak about other alternative hierarchies.

I had simply noticed it-alt.* and oesterreich.* in rone's unified
control.clt and your generated list. I don't have first hand knowledge.

You're one of the most knowledgeable about Usenet hierarchies, that's
why I asked. :)

Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
They both have an associated PGP key but I do not know what is the
policy to create a newsgroup? Is it intended after any demand of
someone and a signed control article is then sent, or is there a
validation by a sort of Board?

I cannot guess what the policies are, but if the control messages
use a PGP key, even if there is some informality about adding a group to checkgroups, I'd call that "managed", given that the proponent would
never send the newgroup message himself. The keyholder has got to be considered to be the hierarchy manager for this purpose.

This has the advantage that there can be checkgroups issued regularly,
an impossibility in truly unmanaged hierarchies.

If there's a checkgroups, that provides satisfactory evidence of
hierarchy management. Similarly, a PGP key provides satisfactory
evidence of hierarchy management.

Agreed.

But if the proponent and not the hierarchy administrator issues newgroup messages in de.alt.* that would never include a PGP key, that requires
a comment.

I believe it is the case.

For instance, the last de.alt.comm.iphone+ipad+co created in 2012:
https://ftp.isc.org/pub/usenet/control/de/de.alt.comm.iphone+ipad+co.gz

Message-ID:
<newgroup-dac.iphone+ipad+co-20120518@thorongil.babylonsounds.com>
From: Simon Paquet <[snipped]>
Control: newgroup de.alt.comm.iphone+ipad+co
Newsgroups: de.alt.admin,de.alt.fan.ipod
Date: Fri, 18 May 2012 12:27:03 +0200

de.alt.comm.iphone+ipad+co is an unmoderated newsgroup, it has been
discussed in de.alt.admin and there was no significant protest.

Bitte richten Sie die unmoderierte Newsgroup de.alt.iphone+ipad+co ein.
Ueber die Einrichtung wurde in de.alt.admin diskutiert und es gab
keinen heftigen Protest.

For your newsgroups file:
de.alt.comm.iphone+ipad+co Apples mobile Geraete und ihre Software.




And afterwards, Thomas takes this newsgroup into account when sending checkgroups for the de.* hierarchy.
And he also cleans up no longer used groups in de.alt.* when appropriate. That's the sort of things we could mention in a revived "hierarchy
notes" file that I could display along with hierarchy information.

I would recommend against listing no.alt.*, nl-alt.*, and de.alt.* as unmanaged.

Noted. Thanks for your motivated reasons. I agree with you.

BTW, I've added it-alt.* and oesterreich.* in the list of unmanaged hierarchies:
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged
--
Julien |eLIE

-2-aLe chemin n'est pas difficile, c'est le difficile qui est le chemin.-a-+
(Kierkegaard)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Adam,

Now that I've glanced at control.ctl again, two other unmanaged >>>>hierarchies are listed:

it-alt.*
oesterreich.*

While looking at making the change in the web pages, I see we did not >>>speak about other alternative hierarchies.

I had simply noticed it-alt.* and oesterreich.* in rone's unified >>control.clt and your generated list. I don't have first hand knowledge.

You're one of the most knowledgeable about Usenet hierarchies, that's
why I asked. :)

I don't read articles in groups in those hierarchies. The Italian and
German words I recognize are mainly from music lessons.

Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies? >>>They both have an associated PGP key but I do not know what is the
policy to create a newsgroup? Is it intended after any demand of
someone and a signed control article is then sent, or is there a >>>validation by a sort of Board?

I cannot guess what the policies are, but if the control messages
use a PGP key, even if there is some informality about adding a group to >>checkgroups, I'd call that "managed", given that the proponent would
never send the newgroup message himself. The keyholder has got to be >>considered to be the hierarchy manager for this purpose.

This has the advantage that there can be checkgroups issued regularly,
an impossibility in truly unmanaged hierarchies.

If there's a checkgroups, that provides satisfactory evidence of
hierarchy management. Similarly, a PGP key provides satisfactory
evidence of hierarchy management.

Agreed.

But if the proponent and not the hierarchy administrator issues newgroup >>messages in de.alt.* that would never include a PGP key, that requires
a comment.

I believe it is the case.

For instance, the last de.alt.comm.iphone+ipad+co created in 2012:
https://ftp.isc.org/pub/usenet/control/de/de.alt.comm.iphone+ipad+co.gz

Message-ID: ><newgroup-dac.iphone+ipad+co-20120518@thorongil.babylonsounds.com>
From: Simon Paquet <[snipped]>
Control: newgroup de.alt.comm.iphone+ipad+co
Newsgroups: de.alt.admin,de.alt.fan.ipod
Date: Fri, 18 May 2012 12:27:03 +0200

de.alt.comm.iphone+ipad+co is an unmoderated newsgroup, it has been
discussed in de.alt.admin and there was no significant protest.

Bitte richten Sie die unmoderierte Newsgroup de.alt.iphone+ipad+co ein.
Ueber die Einrichtung wurde in de.alt.admin diskutiert und es gab
keinen heftigen Protest.

For your newsgroups file:
de.alt.comm.iphone+ipad+co Apples mobile Geraete und ihre Software.

And afterwards, Thomas takes this newsgroup into account when sending >checkgroups for the de.* hierarchy.
And he also cleans up no longer used groups in de.alt.* when appropriate.

He won't list the group in the next checkgroups. I don't think I've
noticed that he issues rmgroups for defunct de.alt.* groups.

That's the sort of things we could mention in a revived "hierarchy
notes" file that I could display along with hierarchy information.

I appreciate your enthusiasm. That file might be edited every 20 years
or so, heh.

I would recommend against listing no.alt.*, nl-alt.*, and de.alt.* as >>unmanaged.

Noted. Thanks for your motivated reasons. I agree with you.

BTW, I've added it-alt.* and oesterreich.* in the list of unmanaged >hierarchies:
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

Thank you.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Hi Adam,

And afterwards, Thomas takes this newsgroup into account when sending
checkgroups for the de.* hierarchy.
And he also cleans up no longer used groups in de.alt.* when appropriate.

He won't list the group in the next checkgroups. I don't think I've
noticed that he issues rmgroups for defunct de.alt.* groups.

There are PGP-signed rmgroup control articles for the removals too.
Example with the last one removed:
https://ftp.isc.org/usenet/control/de/de.alt.rec.flugsimulation.gz

Control: rmgroup de.alt.rec.flugsimulation
Message-ID: <rmgroup-de.alt.rec.flugsimulation-20220205@thangorodrim.ancalagon.de>
Date: Sat, 05 Feb 2022 21:29:34 -0000


But the From address (at thh.name) is not the one expected by the
control.ctl entry (at dana.de) so they were not processed by ftp.isc.org. However, checkgroups for de.* are properly processed, and the de.alt.* newsgroups are then removed at that time according to the ftp.isc.org rules.

That's the sort of things we could mention in a revived "hierarchy
notes" file that I could display along with hierarchy information.

I appreciate your enthusiasm. That file might be edited every 20 years
or so, heh.

:)
--
Julien |eLIE

-2-aNon omnia possumus omnes.-a-+ (Virgile)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Adam,

And afterwards, Thomas takes this newsgroup into account when sending >>>checkgroups for the de.* hierarchy.
And he also cleans up no longer used groups in de.alt.* when appropriate.

He won't list the group in the next checkgroups. I don't think I've
noticed that he issues rmgroups for defunct de.alt.* groups.

There are PGP-signed rmgroup control articles for the removals too.
Example with the last one removed:
https://ftp.isc.org/usenet/control/de/de.alt.rec.flugsimulation.gz

Control: rmgroup de.alt.rec.flugsimulation
Message-ID: ><rmgroup-de.alt.rec.flugsimulation-20220205@thangorodrim.ancalagon.de>
Date: Sat, 05 Feb 2022 21:29:34 -0000

But the From address (at thh.name) is not the one expected by the >control.ctl entry (at dana.de) so they were not processed by ftp.isc.org.

That's very interesting; thanks.

However, checkgroups for de.* are properly processed, and the de.alt.* >newsgroups are then removed at that time according to the ftp.isc.org rules.

. . .

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Adam H. Kerman wrote:

He won't list the group in the next checkgroups. I don't think I've
noticed that he issues rmgroups for defunct de.alt.* groups.

Newsgroups in de.alt.* are removed after a discussion period of at least
7-14 days when there is no "too strong" protest. They are removed by
rmgroup messages sent and signed by the proponent. As most people won't
execute control messages not signed by a hierarchy key, they are really
removed when they are subsequently dropped from the (joined) checkgroups
for de.* (including de.alt.*) sent by the hierarchy maintainers.

All other newsgroups in de.* (excluding de.alt.*) are removed by a formal process of (at least) a RfD, submitted to a moderated newsgroup and posted
by the hierarchy maintainers, followed by a discussion period of (at
least) 14 days, followed by a CfV with a voting period of (at least) for
weeks, needing a majority and a quorum, followed by a result, all
according to a set of rules, posted to a moderated group and arbitrated by hierarchy maintainers, who will sent and sign the control messages after a objection period has passed.

That holds true even if the proponent for the removal of a de.alt.* group
_is_ the member of the hierarchy maintainer team tasked with sending the checkgroups. :-)

-thh
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Julien +LIE wrote:

And what for de.alt.*? Shouldn't it be considered as "unmanaged"?

It's not really unmanaged, as de.* (including de.alt.*) is a managed
hierarchy, so de.alt.* is included in checkgroups messages for de.*. Historically, that was the only option, and after a spectacularly
unsuccessful attempt with a scoped checkgroups we never tried again.

Today, it's mostly moot, due to declining Usenet usage and even more
declining interest and participation in "hierarchy management" of any
kind.

If I remember well, there's a possibility to create any newsgroup in de.alt.* (its control.ctl entry has a doit for a newgroup control
article) and for the sake of not removing them with de.* PGP-signed checkgroups, they are included in de.* checkgroups.

Yes and no; only "legitimate" de.alt.* groups are included in the
checkgroups for de.*, i.e. new groups are not added automatically, but by
hand by someone reading de.alt.admin, the "administrative" group for
de.alt.*

Excluding de.alt.*, de.* is using a formalised RfD/CfV process modelled
after the Big 8 in the 90s while de.alt.* has a kind of consensus-based process: when a proposal is posted and there is no "strong" protest in the
next week (or two weeks), the group may be created by a newgroup message
sent and signed by the proponent (or someone on his or her behalf, if the proponent lacks the expertise to send those messages). Theoretically,
every news server operator can then decide for him- or herself whether
(s)he wants to add that group or not, which ultimately presupposes that
(s)he's either reading de.alt.admin or just listening to their users;
honoring every newgroup message is not a good idea (as in alt.*). In
practice, however, server operators usually simply follow the checkgroups
for de.* - be it by setting up de.alt.* groups only after the checkgroups
has been received or by removing them again if not included in the
checkgroups. So in fact the person sending out the checkgroups for .de*
decides which groups in de.alt.* are "legitimate", i.e. were rightly set
up due to a lack of "too strong" protest.

So we have, on one hand, de.* (excluding de.alt.*) with the moderator (or moderation) of de.admin.news.announce as hierarchy maintainer (or a team
of hierarchy maintainers, since 1997) and strict rules, a formal process
of RfDs, discussion periods, CfV and votes, where all control messages are
sent by the hierarchy maintainer team and signed with their key - and, on
the other hand, de.alt.*, with a fairness based approach, where control messages (new/rmgroups) are sent and signed by the proponent.
Theoretically, both systems co-exist; in fact, the hierarchy maintainer
team has the last say even on groups in de.alt.* due to their inclusion in
the checkgroups for the whole hierarchy. While mostly theoretical, there
were instances of "control message wars" when not all participants agreed wether there was "strong protest" or not.

Today, that's mostly just of historical interest, as most people able to
send control messages or conduct votes (or even interested in discussing changes in the list of newsgroups) that are still active _are_ members of
the hierarchy maintainer team. *shrug*

tl;dr: Technically and factually, de.* is a managed hierarchy; newgroup
(and rmgroup) messages for de.alt.* are vetted before inclusion in the checkgroups to check that "due process" was followed.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: news.admin.hierarchies

Adam H. Kerman wrote:

But if the proponent and not the hierarchy administrator issues newgroup messages in de.alt.* that would never include a PGP key, that requires
a comment.

de.alt.* had been modelled after alt.*, as de.* had been modelled after
the Big8, so control messages for de.alt.* are traditionally sent by
proponents (signed with their keys) or by someone acting for the
proponent. Those groups are added to or removed from the checkgroups for
de.* by the hierarchy maintainer team; while - theoretically - just a
technical necessity, that makes the hierarchy maintainers the final
arbiter of disputes whether due process was followed before the control
message was send.

Historically, the rights and sinecures of de.alt.* have been jealously
defended against perceived infringements by hierarchy maintainers. :-)
Today, that's mainly moot as there are not many users left (and even less interested in hierarchy administration or technically inclined or
qualified to sent control message).

Anyway, all groups in the checkgroups are created (and all missing groups
have been removed) by due process; it's just a very different process for de.alt.*

-thh
--- Synchronet 3.21d-Linux NewsLink 1.2