TRS Deprecation in Wiki, was: QPD2012

Status
Not open for further replies.

ecps92

Member
Joined
Jul 8, 2002
Messages
14,360
Location
Taxachusetts
Please stop undoing my Wiki Edits, until you enable Private Messages.

The Wiki is not the RRDB and we should not be relying on DB Edits, which have been submitted previously and added to Comments to dictate Valid Wiki information
:mad:
 
Last edited:

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Good afternoon ecps92,

For other reasons, my PMs and emails are limited to administrators/moderators only, and will remain that way for the foreseeable future. Sorry for any inconvenience.


My Wiki-edits were/are not trying to make your life difficult, nor trying to upset you.

I look forward to your comments on the thoughts below.


In my opinion, this scenario is applicable to more than you and me (though we have bumped into it a few times already) and might be appropriate for Wiki Admins and other senior Wiki editors to discuss here, because it relates directly to a data-accuracy standard for the Wiki.

Please stop undoing my Wiki Edits, until you enable Private Messages.

The Wiki is not the RRDB and we should not be relying on DB Edits, which have been submitted previously and added to Comments to dictate Valid Wiki information
:mad:

As you know...
  • The DB is the repository for confirmed data.
  • The Wiki is the repository for unconfirmed data, and is the repository for the confirmed data that does not fit into the DB.
  • The deprecation-status of a TRS is clearly a part of the confirmed data vetted and managed in the DB by the DBAs, and as such the DB's data takes precedent over a note or indicator or category-assignment on a corresponding Wiki page, which any Wiki-editor can place there on purpose or by accident.


In my opinion,
  • ...flagging/categorizing a TRS' primary Wiki page with a deprecation-status different from the confirmed status in the DB is...

    • confusing to say the least, not just to those who regularly navigate the Wiki, but I expect even more so to those who are new to the Wiki, especially if there is no accompanying proof or explanation posted as a narrative on the edited Wiki page,

    • creating in the mind of any Wiki-visitor a certain amount of skepticism and distrust of the Wiki data because the basic information that has the appearance of being more official than a note/comment, does not agree with the DB.

    • something that should be avoided, and corrected when found.


  • ...data that should be managed in the DB, should actually be managed in the DB, not the Wiki. This means:

    • when a TRS becomes deprecated, submit the deprecation update to the DB. If it goes unhandled or gets rejected, then politely and patiently work with the DBA(s) to figure out what additional proof-of-deprecation is needed to get the TRS properly marked in the DB.

    • If the DBAs seem to be slacking-off, then contact the Lead DBA with your concern(s). From what I have seen, DBAs are intent on doing a good job and do so very regularly. Some hiccups or speed-bumps might happen, but that can be worked out with patient professionalism.


  • When a TRS (or anything) is renamed in the DB, we rename the corresponding Wiki page(s) accordingly. Same synchronization goes, or should go, regarding the deprecation-status of a TRS.


As only one member of RR's diverse Wiki community, my goal is to contribute, building upon everyone's years of good work including yours, in a collaborative way, so that:

  • the Wiki is always consistently and easily navigable for the newest and least-trained Wiki visitor,
  • the Wiki presents clearly and concisely all data which augments the confirmed DB-data,
  • the Wiki's underlying structure supports future growth in several ways.


Again, I am not trying to make your life difficult, nor trying to upset you. Also, as far as I know, permitting non-Admin/Mod PMs is not a prerequisite for editing the Wiki.

I look forward to your thoughts on this.


It also might be best for the Wiki Admin(s) also to comment on this, so that we, the whole Wiki community, all have a common direction moving forward.

Question is: Generally, should the TRS' deprecation-status in the Wiki match the status shown in the DB?



Best Regards.
 
Last edited:

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,292
Location
Central Indiana
Question is: Generally, should the TRS' deprecation-status in the Wiki match the status shown in the DB?
My gut reaction to this question is "not necessarily". The Wiki is intended to be fluid and readily editable by all RR members. The DB is for confirmed and verified data. If someone has data that a system is being or has been deprecated, I see no problem with noting that in the Wiki. Of course, once that status is confirmed, a DB submission should be made so the DB can be updated.
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Good evening W9BU,

My gut reaction to this question is "not necessarily". The Wiki is intended to be fluid and readily editable by all RR members. ...
I understand and agree wholeheartedly.


...The DB is for confirmed and verified data. If someone has data that a system is being or has been deprecated, I see no problem with noting that in the Wiki...

As you know, when a TRS is deprecated, the following deprecation-steps happen:
  • (1) The TRS is deprecated in the DB.
  • (2) The category gets changed on the TRS' primary Wiki page.
  • (3) A template is applied to the TRS' primary Wiki page to indicate deprecation.
  • (4) All referring Wiki pages are updated accordingly to indicate deprecation of the TRS.


Notation of deprecation or future deprecation is where the current issue seems to be focused.


As a method of "noting that in the Wiki" (prior to actual deprecation in the DB), I am in favor of someone adding narrative text to the main body of the TRS' primary Wiki page, indicating something like:
  • "the system should be deprecated in the DB because (reason)",
  • "the system is no longer used, and should be deprecated"
  • "the system has been decommissioned, and should be deprecated"
  • or whatever the situation's details require as an explanation for deprecation



I am not in favor of actually going through deprecation-steps 2 through 4, as listed above, until the TRS has actually been deprecated in the DB.


The reason for this is consistency in presentation and in navigation. When a person is looking for information about a particular TRS, whether they start in the DB or in the Wiki and navigate to the other, they are not expecting to look for a "valid" TRS in one location and then a "deprecated" TRS in the other.

Until the TRS is actually deprecated in the DB, it seems cleaner and clearer to only note in a narrative on the Wiki page that the TRS should become deprecated or that a request for deprecation has been submitted to the DB for this TRS, and not to do deprecation-steps 2 through 4 at that time.



...Of course, once that status is confirmed, a DB submission should be made so the DB can be updated.

If deprecation-steps 2 through 4, as listed above, are done in the Wiki before deprecation is done in the DB, then the Wiki-editor making the change really needs to add either a narrative to the TRS' wiki page, or sufficient edit-comments to the history-log, so that other Wiki-editors clearly know that the request for deprecation has been submitted to the DB, and a concise reason for deprecation. Otherwise it can look like an unexplained change that disagrees with "known and accepted" information in the DB.


Also, in those situations where a request-for-deprecation gets denied/rejected by the DBA, how should it get resolved in the Wiki? Only the requester gets notified that the DBA rejected their submission, but no one else learns about its rejection. The DBA would have a reason for rejecting the request. That reason should be valid enough that the Wiki should also not be deprecated. Again, as mentioned earlier, a narrative-note on the Wiki page seems appropriate for yet-to-be deprecated TRS's, but actually deprecating the Wiki page seems confusing if the DB is not deprecated.

Only one opinion.


As with previous procedural questions, I want us moving in the same direction and will certainly follow whatever you prefer in marking yet-to-be deprecated TRS's in the Wiki.


Thanks for your time and advice,
 
Last edited:

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,292
Location
Central Indiana
As you know, when a TRS is deprecated, the following deprecation-steps happen:
  • (1) The TRS is deprecated in the DB.
  • (2) The category gets changed on the TRS' primary Wiki page.
  • (3) A template is applied to the TRS' primary Wiki page to indicate deprecation.
  • (4) All referring Wiki pages are updated accordingly to indicate deprecation of the TRS.
By doing so, you are letting the DB drive the Wiki. The Wiki needs to be more flexible than that. I see no problem with the above process, but I still believe that a Wiki article can indicate that a system is deprecated before the DB does.
 

ecps92

Member
Joined
Jul 8, 2002
Messages
14,360
Location
Taxachusetts
And the DB Admin had, put that in the notes section, Long Ago.

Not my job to make sure they follow the exact rules and delete or deprecate, the info was submitted and noted.

It just seems we are making the Wiki harder for users


My gut reaction to this question is "not necessarily". The Wiki is intended to be fluid and readily editable by all RR members. The DB is for confirmed and verified data. If someone has data that a system is being or has been deprecated, I see no problem with noting that in the Wiki. Of course, once that status is confirmed, a DB submission should be made so the DB can be updated.
 
D

DaveNF2G

Guest
I believe the DB, as official repository for confirmed data, should drive everything else.

Facts first.
 

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,292
Location
Central Indiana
In my opinion as the Wiki Manager...

The DB is for confirmed data presented in a well-defined format suitable for human consumption and import by DB-aware scanners and software.

The Wiki is for unconfirmed data, system usage patterns, personal observations, etc., presented in a less-tightly-controlled format.

If the DB were to drive the Wiki, then there would be no point to the Wiki as the DB would be the repository for all data.
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,361
Location
Bowie, Md.
...except for the point where the wiki holds information that the database can't, such as FTOs and RIDs.

Mike (the former wiki admin)
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
By doing so, you are letting the DB drive the Wiki. The Wiki needs to be more flexible than that...
In my opinion as the Wiki Manager...
The DB is for confirmed data presented in a well-defined format suitable for human consumption and import by DB-aware scanners and software.
The Wiki is for unconfirmed data, system usage patterns, personal observations, etc., presented in a less-tightly-controlled format.
If the DB were to drive the Wiki, then there would be no point to the Wiki as the DB would be the repository for all data.
...except for the point where the wiki holds information that the database can't, such as FTOs and RIDs.
The view from my chair is that
  • RadioReference is one unified entity, not a "DB-vs-Wiki driving-competition" (an idea which seems self-defeating and inaccurate at its base premise). There might be personalities behind the scenes that have some issues between themselves, but the function of the website's components should be unified, consistent, and symbiotic, not strangled by personality conflicts between administrators and/or contributors.

  • Consequently, I expect certain types of continuity between the DB and Wiki, while each serves its purpose based upon its capability (DB = storage of confirmed data; Wiki = storage of all other data -- any unconfirmed, and any confirmed that cannot be stored in the DB.).

More specifically...
  • RadioReference should ensure its continued success overall by being a website that is functionally unified, even though the DB, and Wiki, and Classifieds, and Forums, and BCFY/Live Audio, are clearly different components, and administered by different teams.

  • All parts of the whole should work together as a cohesive system of storing, presenting, searching, navigating, and finding data.

  • Visitors should find site-navigation convenient and obvious so that they can navigate in any order between DB and Wiki and Forums, with respect to a particular radio-system.

  • When reasonable and even if only as a courtesy, the data being collected and prepared in the Wiki for DB-submission should be formatted in a way that makes it easier for the DBA to copy-paste the new data into the DB

  • When data from the DB (considered confirmed) is replicated manually in the Wiki (without using Wiki Extensions), the data in the Wiki should not be updated until the data in the DB is updated, just as if a Wiki extension was being used.

    Examples include TRS data often displayed in InfoBoxes including TRS Deprecation-status.

RadioReference's history clearly shows that...
  • The DB formerly held data that it no longer holds, data which was migrated to the Wiki, to improve DB-structure, reduce DBA-labor, and allow the Wiki community to more easily and rapidly update frequently-changing data that are not required for programming radios/scanners, like FTOs and RIDs/UIDs.

    This alone shows the value of the Wiki regardless of the "who is driving?" question (which again is a question that I believe is based on a wrong premise).

  • The Wiki has always been used as the place to document new research, unconfirmed or partially confirmed data, and things that don't fit in the DB, like lists of fire stations, etc.

If the "who is driving" model is seriously a question, then think of Radio Reference like a sports team traveling in a van or bus, where different team members rotate through the driving duties. The DB and Wiki influence each other, or each one is driving at different times. Some examples...
  • How the DB influences the Wiki:
    • When a DBA renames a TRS, and airport page, a county page, or anything else, in the DB, then the Wiki must do likewise to maintain proper consistency and continuity between the DB and Wiki.
    • When the DB is updated/upgraded to accomodate a new technology like TETRA, or DMR, or ProVoice, or NXDN, or P25P2, or the new one coming up next year (whatever it is), the Wiki makes related adjustments to also accomodate such data, to maintain proper consistency and continuity between the DB and Wiki
    • When a DB listing is updated, the Wiki pages which use the Extensions, automatically have their content updated which is pulled from the DB
    • When a DBA creates a new TRS, but has only a skeleton of information, the related Wiki pages become the collection-point for the unconfirmed information during the research process.
    • Confirmed information stored in the DB can/should be removed from the Wiki.
    • ALL Data in the DB is considered confirmed/vetted, until proven otherwise.

  • How the Wiki influences the DB:.
    • When new discoveries are made about known or unknown systems, the Wiki is the data collection point until confirmed data can be submitted to the DB, at which time the DB is updated by a DBA accordingly.
    • When new discoveries are made about new technologies, the Wiki and the Forums often are where ideas and solutions are identified before DB structure gets updated accordingly.
    • When searches lead visitors initially to a Wiki page, consistent presentation-style and clear navigational aides can easily lead the visitor to the related section(s) of the DB.
    • Certain characters are disallowed in page-names in the Wiki (amperand, pound, etc.). When such is discovered in the Wiki, this leads to a page-name change in the DB (via a DB submission), and a matching page-name change in the Wiki.


---
As you know, when a TRS is deprecated, the following deprecation-steps happen:
  • (1) The TRS is deprecated in the DB.
  • (2) The category gets changed on the TRS' primary Wiki page.
  • (3) A template is applied to the TRS' primary Wiki page to indicate deprecation.
  • (4) All referring Wiki pages are updated accordingly to indicate deprecation of the TRS.

I see no problem with the above process, but I still believe that a Wiki article can indicate that a system is deprecated before the DB does.
The above process does not conflict with having an article indicate that a system is deprecated before the DB does. I just believe it should be done with a narrative note explaining a future change that should take place without actually deprecating the Wiki page. This way the information is shared but the consistency between Wiki and DB is maintained.

Since there is no way to tell if or when a Wiki-editor submitted as request-for-deprecation to the DB, nor if/when the DBA rejected or ignored the request, this is one of those time when a change in the Wiki should follow a change in the DB. I think the consistency is a bigger deal than "who is driving the bus".


Again, just one opinion.

I will follow your lead. I just want us all moving in the same direction regarding procedure.

As always, Thanks for your time and advice,
 

wa8pyr

Technischer Guru
Staff member
Lead Database Admin
Joined
Sep 22, 2002
Messages
6,982
Location
Ohio
As you know, when a TRS is deprecated, the following deprecation-steps happen:
  • (1) The TRS is deprecated in the DB.
  • (2) The category gets changed on the TRS' primary Wiki page.
  • (3) A template is applied to the TRS' primary Wiki page to indicate deprecation.
  • (4) All referring Wiki pages are updated accordingly to indicate deprecation of the TRS.

Notation of deprecation or future deprecation is where the current issue seems to be focused.

As a method of "noting that in the Wiki" (prior to actual deprecation in the DB), I am in favor of someone adding narrative text to the main body of the TRS' primary Wiki page, indicating something like:
  • "the system should be deprecated in the DB because (reason)",
  • "the system is no longer used, and should be deprecated"
  • "the system has been decommissioned, and should be deprecated"
  • or whatever the situation's details require as an explanation for deprecation

By doing so, you are letting the DB drive the Wiki. The Wiki needs to be more flexible than that. I see no problem with the above process, but I still believe that a Wiki article can indicate that a system is deprecated before the DB does.

But the DB does and should drive the Wiki in this type of situation. While it is correct that the database and the Wiki should be viewed as parts of the whole, the sole reason for the existence of a Wiki page related to a particular system is the mere existence of the system itself, and it's purpose is to convey information which cannot be conveyed by the database.

An earlier post mentioned concern for users' trust in the accuracy of the data in the Wiki, but the nature of the Wiki as user-editable makes that a given, due to the potential for rumor or personal opinion to color the information. The bigger concern is trust in the accuracy of the database. If the Wiki were to frequently display important information (such as deprecation status) which conflicts with the database, that can undermine trust in not only the Wiki, but the database itself.

The purpose of a system-related Wiki page is to enhance and expand upon the information contained in the database, by providing a place for information which isn't appropriate for the database (such as radio IDs, details on dispatch centers, patrol zones, fire districts, unconfirmed information worthy of investigation and so on). It should not duplicate what is in the database unless there is a real need to do so for a specific point of clarity.

As far as deprecation is concerned, the proper procedure is for notice of system deprecation to be made by submission to the DB first (or at least simultaneously) with a valid reason for deprecation given, such as one of the reasons quoted above. For situations where the decommissioning of a system is pending or possible, that information can certainly be put in the Wiki, but should also be accompanied by a dated news entry on the system in the database. This way the Wiki and the database remain in sync.
 

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,292
Location
Central Indiana
...flagging/categorizing a TRS' primary Wiki page with a deprecation-status different from the confirmed status in the DB is...
Allow me to roll this small grenade under the table...

If the "[state] Deprecated Trunked Systems" categories did not exist, would this whole matter even be an issue?

Do the "[state] Deprecated Trunked Systems" categories serve a sufficient purpose to justify their existence?

Has the Wiki gone too far by subdividing Trunked Systems into deprecated and non-deprecated systems?
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Allow me to roll this small grenade under the table...

If the "[state] Deprecated Trunked Systems" categories did not exist, would this whole matter even be an issue?

Do the "[state] Deprecated Trunked Systems" categories serve a sufficient purpose to justify their existence?

Has the Wiki gone too far by subdividing Trunked Systems into deprecated and non-deprecated systems?


Good afternoon W9BU,

I see no grenade here, though your question might be headed in a little different direction than the issue ecps92 originally addressed. So, I will reply to both.

The issue that started this thread was the following sequence of actions:
  • 2017-05-21 22:55 - At least one person submitted a deprecation-request to the DBAs for the TRS because the "Important Note" in the DB indicated the TRS was deprecated but the system was not officially marked deprecated.
  • 2017-05-23 07:28 - ecps92 assigned the "Deprecated" category to the TRS' primary Wiki page.
  • 2017-05-23 12:45 - I reverted ecps92's edit because the DB did not show the TRS as deprecated.
  • 2017-05-24 07:19 - ecps92 re-assigned the "Deprecated" category to the TRS' primary Wiki page.
  • 2017-05-24 13:33 - I reverted it again for the same reason.
  • 2017-05-25 08:10 - ecps92 re-applied the "Deprecated" category.
  • 2017-05-25 08:15 - ecps92 started this thread because my PMs are restricted to admins/mods only.
  • 2017-05-25 15:55 - the DBA marked the DB page as deprecated
  • 2017-05-26 13:18 - I applied a template to indicate deprecation because it was deprecated in the DB by this time.
..which led to this thread's original discussion about whether a TRS' primary Wiki page should be officially deprecated before the corresponding DB-page is officially deprecated. My answers in previous posts cover this topic as we have discussed it so far.


---
Regarding the categories and separation of deprecated and non-deprecated TRS's in the Wiki:
  • Several years ago, The "[state] Deprecated Trunked Systems" categories were created to mirror the DB's "Deprecated Systems" page which still makes available, but removes from the current "[state] Trunked Radio Systems" category, those TRSs that are no longer valid and likely of very little interest except historic.

  • All of the "[state] Deprecated Trunked Systems" category-tree branches could be removed and the issue initially raised by ecps92 would still exist, because the Primary Wiki page of a deprecated TRS is also flagged with the deprecation status via a template (Deprecation process Step 3 in the earlier posts). (Edit: The template is also applied to the deprecated TRS's secondary Wiki pages for clarity.)

    The related template was generally implemented in the Wiki because in the past, as newer TRSs were added to the DB, the older TRSs (which were being replaced by the newer TRSs) were kept active during transition but later deprecated after transition was complete.

    However in the Wiki, it was not always obvious to the occasional Wiki-editor, and at times even to the regular Wiki-editors, which TRS was being represented by which Wiki page. Information like RID and TG lists along with other information were being confused and misapplied to the wrong TRS' Wiki page.

    So, initially using a manual process, and later using a template, the primary Wiki pages for the deprecated TRSs were marked as deprecated, to help all Wiki editors avoid placing wrong information onto the wrong Wiki page. (The problem was magnified when TRS's were renamed and Wiki pages became disconnected from their related DB pages, sometimes without being noticed for years.)

  • At one time, there was even an effort to have a set of separate Wiki-pages that listed Deprecated TRSs, much like the "Trunked Radio Systems (ST)" pages list the current ones. Those pages have been blanked and deleted because they wound up not being updated in a timely manner, often because it involved moving the deprecated listing from one page to another. Now the lists of deprecated TRSs are being placed at the bottom of the "Trunked Radio Systems (ST)" pages, and related links on other referring pages (like County pages) also get a note about the deprecation. This is done (instead of deleting the links) to prevent orphan pages.

  • If I thought removing the "[state] Deprecated Trunked Systems" category was the solution to ecps92's original issue here, I would be the first to do it, without hesitation. I don't see that step solving what is being discussed here. I'm not sure what it would solve if anything.

  • The problem being highlighted by ecps92's original post existed years ago before I joined the site, and is coming to light because for at least the past three years, several of us have been marking TRS Wiki pages as deprecated for clarity and consistency so that it is obvious to which TRS in the DB the Wiki page corresponds. To me, the deprecation-status is part of the identifying characteristics of the TRS.

    As far as I can tell, the issue currently is not whether a TRS page gets marked as deprecated, the issue is when and how it gets marked. (As explained above, having a deprecated TRS not marked as deprecated in the Wiki has already led to confusion, which is why those pages are so marked now.)


  • In a thread several years ago, I expressed my thoughts about generally not being in-favor of the InfoBoxes used on the TRS pages. I have since learned to appreciate their usefulness to all Wiki-editors as you and ka3jjz already did years ago.

    I think it is a good thing that we replicate the known TRS info in the Wiki-page's InfoBox. Doing so gives a clean consistent presentation of the details for the particular TRS without navigating to the DB. This helps the Wiki-visitor feel assured they are on the correct Wiki page. (If a Wiki-extension existed that would draw from the DB all of the contents normally displayed in the TRS InfoBox, that might simplify quite a few things, but I don't believe that option is really practical if possible.)

    The DB's deprecation status should be replicated accordingly for consistency and for the same clarity about which TRS is being represented on the Wiki page. This helps assure the Wiki-editors/visitors that they are on the correct page. Again, to me, the deprecation-status is part of the identifying characteristics of the TRS.

  • My default navigation method is still by the Catergory-Tree. I find that to be more consistently useful than the search-tool or the page-to-page navigation (though I use all of them), because many pages have red-links that lead nowhere.

    The category-pages list Wiki pages that exist and that have some amount of content related to the category-name. I might be the only one who uses the categories for regular navigation.

    Having the "[state] Deprecated Trunked Systems" category branches is useful because it keeps the "[state] Trunked Radio Systems" category list as a current-TRS-only list. In the Wiki, just as in the DB, visitors save time when they do not have to read outdated items in a list, unless they are searching for an outdated item specifically.
Thanks for taking time to read my opinions.


Sir, if you, as Wiki-Admin, want the "[state] Deprecated Trunked Systems" branch of the category-tree eliminated, just give the word -- I will do it. Even if I disagree with the decision, I will follow your lead on that as well as this topic about TRS deprecation.

I think I have expressed my opinions clearly on ecps92's topic. Others might still want to express their opinions. I'm going to post this now, so I don't repeat myself anymore than I have already on that issue.


Very Respectfully,
 
Last edited:

ecps92

Member
Joined
Jul 8, 2002
Messages
14,360
Location
Taxachusetts
Honestly the Wiki has WAY too MANY Categories/Sub Categories for even an experienced user to do editing.


I think we need to get back to Basics, but that is just me a little ole Wiki contributor

Do we really need Category edits and Template changes every day ??

I [IMHO] feel we lost sight of the RRDB vs Wiki when folks found out how to Link the actual RRDB Data to display in the Wiki, just post the URL to the RRDB if folks want to compare the difference in the data

BTW this whole thing began, because the RRDB didn't explicitely indicate the DOA status, however the DB Admin had put it in the notes.

Which opens up the whole Deprecrated topic [Not TRS related] of one persons interpretation of no longer used. Just because you as a Scannist have not heard it in awhile doesn't mean it is not in the Radios :cool:

Allow me to roll this small grenade under the table...

If the "[state] Deprecated Trunked Systems" categories did not exist, would this whole matter even be an issue?

Do the "[state] Deprecated Trunked Systems" categories serve a sufficient purpose to justify their existence?

Has the Wiki gone too far by subdividing Trunked Systems into deprecated and non-deprecated systems?
 

ecps92

Member
Joined
Jul 8, 2002
Messages
14,360
Location
Taxachusetts
Which should be addressed, if your going to Edit and Undo other folks work, communicate with them, so you need to enable PM's from us lowly contributors

Good afternoon W9BU,

I see no grenade here, though your question might be headed in a little different direction than the issue ecps92 originally addressed. So, I will reply to both.

2017-05-25 08:15 - ecps92 started this thread because my PMs are restricted to admins/mods only.

Thanks for taking time to read my opinions.


Sir, if you, as Wiki-Admin, want the "[state] Deprecated Trunked Systems" branch of the category-tree eliminated, just give the word -- I will do it. Even if I disagree with the decision, I will follow your lead on that as well as this topic about TRS deprecation.

I think I have expressed my opinions clearly on ecps92's topic. Others might still want to express their opinions. I'm going to post this now, so I don't repeat myself anymore than I have already on that issue.


Very Respectfully,
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Honestly the Wiki has WAY too MANY Categories/Sub Categories for even an experienced user to do editing.


I think we need to get back to Basics, but that is just me a little ole Wiki contributor

The existing threads in the Wiki forum relating to the categories make it clear that the categories were subdivided because the category-tree suffered from "the basics", leaving many category pages way too long, making it impossible to navigate by the categories to find a page with the desired type of information.

As it is now, the category-tree
  • is no longer fragmented,
  • is structured according to categories one normally encounters in life,
  • is uniform in the presentation of the category-pages, and
  • provides lists short enough that a Wiki-visitor can quickly determine if their desired page exists or does not exist in a particular category.

For Wiki editors' convenience, and for anyone's navigational convenience, in each state's primary category, is a Wiki article named "Standardized Categories for (state)" which lists all of the standardized categories for that state, with each name conveniently wrapped with square-brackets, so that an editor can simply copy-paste the desired categories into their article(s). For each category, there is also a "Related-Changes" link, so that any interested person can click the link and see a list of changes that relate to that corresponding category.

I appreciate your conscientiousness in wanting to apply the correct categories to any article you edit, and your desire for convenience when doing so. At the same time, the category-tree must be useful in helping to narrow the breadth of articles a particular category contains; otherwise, we return to the same problem we had before, when categories were too large.

It might make more sense to have a conversation about categories in one of the existing threads/discussions, so that those conversations all stay together, and so that previous conversation is ready and relevant to current discussion.


Do we really need Category edits and Template changes every day ??
  • The category-tree project was completed last year. Some pages need their categories updated because content has been updated. That's just the way the Wiki works.

    The InfoBox template project (also discussed in an earlier thread) is now moving from the testing phase into the implementation phase. It will be completed as soon as possible, and involves a lot fewer Wiki-pages than the category-project did. Please be patient.

  • As explained in earlier threads, if you wish to see Recent Changes without the changes that I make, you can do so very easily, by filtering out the "minor" changes.

    Here's the direct link that you can bookmark: Recent Changes (not minor)

  • You can filter even more by also only seeing the main name-space, and not the category-space or template-space. This way, when template or categories are created or edited, you won't see it.

    The direct link that you can bookmark is: Recent Changes (not minor, in Main namespace only)


I [IMHO] feel we lost sight of the RRDB vs Wiki when folks found out how to Link the actual RRDB Data to display in the Wiki, just post the URL to the RRDB if folks want to compare the difference in the data

If the Wiki extensions were used more often, then it would be easy to compare DB data to Wiki data because both would be displayed in the Wiki-page. Otherwise, any comparison between Wiki data and DB data involves jumping back and forth between the DB and Wiki pages, which makes comparisons more difficult.

Another project to improve navigation by adding "Return to DB and Wiki page links" onto every Wiki page has been going on for several years as well. It requires visiting and likely editing every Wiki page. When that project is done, navigation between DB and Wiki will be consistently easy. Of course, when anything in the DB gets renamed, the "Return to" links must be updated. (All discussed in an earlier thread about DB-Wiki disconnections.)



BTW this whole thing began, because the RRDB didn't explicitely indicate the DOA status, however the DB Admin had put it in the notes.
It began because the Wiki page's category was updated before the DB was properly deprecated.
Someone other than you also noticed the narrative comment on the DB page and submitted a DB-deprecation request 2 days before you changed the Wiki page's category.

As you know, from the Wiki-edit comments that we both posted in the Wiki, I reverted your change to maintain synchronization with the DB, and you deprecated the Wiki page because you knew the TRS was dead. Difference being, I was waiting for the DB to be updated, and you weren't.
  • 2017-05-22 23:50 QDP2012 used Template:Infobox_TRS_TypeII_US_Pub
  • 2017-05-23 07:28 Ecps92 (no comment)
  • 2017-05-23 12:45 QDP2012 updated categories
  • 2017-05-23 12:45 QDP2012 added "Return to" link(s) to DB and Wiki pages
  • 2017-05-24 07:19 Ecps92 It is DEAD - has been since atleast 2011/2012
  • 2017-05-24 13:33 QDP2012 Thanks for the update, but please get the TRS deprecated in the DB first, so that the DB and Wiki stay synchronized. Thanks!
  • 2017-05-24 13:34 QDP2012 (no comment)
  • 2017-05-25 08:10 Ecps92 Stop undoing edits, until you enable Private Messages
  • 2017-05-26 13:38 QDP2012 used Template:Infobox_TRS_TypeII_US_Pub_Dep



Staying on topic, The issue being discussed here is whether or not a Wiki-page should be formally deprecated before the DB is formally deprecated, OR whether the Wiki-page deprecation should wait until the DB is properly deprecated, for continuity.

<repeat-myself>A narrative-note should be used in the Wiki prior to official deprecation in the DB, as explained in earlier posts.</repeat>

We also are not discussing whether or not a DBA did or did not do their job. That's a different conversation with different people (the DBAs and Lead DBA, etc.) for a different thread. (I am sure you realize that if a DBA had complete the DB-request and deprecated the TRS before you changed the Wiki page's category, we would not have had any part of this conversation, and you would not have experienced your frustration(s).)


Which opens up the whole Deprecrated topic [Not TRS related] of one persons interpretation of no longer used. Just because you as a Scannist have not heard it in awhile doesn't mean it is not in the Radios :cool:

I absolutely agree, and am glad you pointed this out clearly, for everyone's benefit. Inactivity is not the same as deprecation. Notes about inactivity can be added to an appropriate Wiki page. Deprecation should be submitted to the DB.



..
  • 2017-05-25 08:15 - ecps92 started this thread because my PMs are restricted to admins/mods only.
...
Which should be addressed, if your going to Edit and Undo other folks work, communicate with them, so you need to enable PM's from us lowly contributors

As mentioned earlier in this post, the comments we both placed and saw in the Wiki-edits were clear about why we each made changes. Our reasons have not changed since we made the edits. This thread has not added clarity on why the edits were made, and neither would PMs. This thread's discussion on how the DB and Wiki relate, and what action should precede another is really at the heart of what happened, and is a procedure-related discussion which should take place in the Forums so that the Wiki Admins and Wiki community can comment. The issues here are larger than two people individually.




Thanks again for your time and effort with the Wiki. Again, I'm not trying to create problems or stress for you or anyone else in our Wiki community. I am trying to make the improvements mentioned earlier in this thread.


Have a great day,
 

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,292
Location
Central Indiana
Staying on topic, The issue being discussed here is whether or not a Wiki-page should be formally deprecated before the DB is formally deprecated, OR whether the Wiki-page deprecation should wait until the DB is properly deprecated, for continuity.
Repeating and amending what I said in post #5 of this thread:

If someone has data that a system is being or has been deprecated, I see no problem with noting that in the Wiki. Of course, once that status is confirmed, a DB submission should be made so the DB can be updated. Once the DB system is marked deprecated, the Wiki category and template can be changed for that article to reflect the DB status.
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
...
We also are not discussing whether or not a DBA did or did not do their job. That's a different conversation with different people (the DBAs and Lead DBA, etc.) for a different thread. (I am sure you realize that if a DBA had complete the DB-request and deprecated the TRS before you changed the Wiki page's category, we would not have had any part of this conversation, and you would not have experienced your frustration(s).)...

After re-reading this, please let me clarify that this is not intended to suggest anything bad about the DBAs. This was only an attempt to illustrate how discussions might have been different if the sequence of events were different. I think the DBAs do a very good job.

Thanks,
 
Status
Not open for further replies.
Top