Wikipedia:Articles for deletion/Code page 875

This discussion was subject to a deletion review on 2020 September 15.
For an explanation of the process, see Wikipedia:Deletion review.

The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The result was transwiki and delete. There is very strong consensus here on two different fronts: First, that these articles are not encyclopedic, they don't pass WP:GNG, and they don't belong on WP. Second, that the information in these articles is exceedingly useful, valuable, and not easily found elsewhere. However, simply being valuable and useful is not enough to warrant inclusion as a standalone article in Wikipedia, so the articles must eventually be deleted.

In the interests of developers, engineers, and other humans around the world that find this content useful, it seems reasonable to apply some unconventional leniency to this situation, and allow for a reasonable amount of time for this content to be relocated to a more suitable place before it is deleted. To this end, I'm willing to offer the following terms:

The articles will not be immediately deleted or moved, they will stay where they are for now.
Editors that are interested in preserving this content are encouraged to immediately start discussing where to move this content and how to best achieve that.
In 30 days (on August 30th), I will return to delete all of these articles. If more time is needed to complete the transwiki process, I will consider requests to extend the period of time slightly beyond 30 days, but only if there is clear evidence of significant progress being made.
If the transwiki process is completed before 30 days, please inform me and I will delete the articles sooner.

‑Scottywong | [gab] || 19:50, 31 July 2020 (UTC)[reply]

Code page 875[edit]

[Hide this box] New to Articles for deletion (AfD)? Read these primers!

(Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL)

This is a mass nomination of all EBCDIC code pages, following on from the closure of Wikipedia:Articles for deletion/EBCDIC 389.

While these pages are verifiable, none of them are notable, as there have been no reliable, independent sources discussing (not just mentioning or reposting) individual code pages.

This nomination is explicitly not for the page EBCDIC, which is a notable subject: and the code pages itself are discussed in that article and already listed in Code page#EBCDIC-based code pages.

I have chosen to only nominate EBCDIC code pages here because that includes already 100+ pages, and because other types of code pages may be notable, I haven't checked (though I suppose many may have the same issues and may need deletion as well).

Fram (talk) 13:30, 3 July 2020 (UTC)[reply]

Note: This discussion has been included in the list of Language-related deletion discussions. Fram (talk) 13:30, 3 July 2020 (UTC)[reply]

Note: This discussion has been included in the list of Computing-related deletion discussions. Fram (talk) 13:30, 3 July 2020 (UTC)[reply]

Delete these codepage reproductions, per WP:INDISCRIMINATE: they are not encyclopedia articles and so do not belong in the encyclopedia. None of these topics is individually and independently notable. —David Eppstein (talk) 16:31, 3 July 2020 (UTC)[reply]
- None of the sub-cases of WP:INDISCRIMINATE really applies to these articles. All of them have context and references to independent sources (including the Unicode consortium) GSchizas (talk) 22:06, 5 July 2020 (UTC)[reply]
Transwiki, perhaps to WikiBooks, then delete. I have not checked all the nominated articles, but those I have looked at don't have notability in the sense of secondary sources writing about the individual code page history, impact, etc. I agree that these pages are not suitable as standalone articles. In the previous AfD, there was a consensus among knowledgeable editors that the information was verifiable and valuable. So while these are not suitable for Wikipedia articles, perhaps those editors could transwiki the lot of them to an EBCDIC Wikibook. --{{u|Mark viking}} {Talk} 18:29, 3 July 2020 (UTC)[reply]
- The previous AfD was not really resolved. The result was "no consensus". GSchizas (talk) 17:52, 6 July 2020 (UTC)[reply]
  - I never said it was. Please sign your comments. --{{u|Mark viking}} {Talk} 09:52, 6 July 2020 (UTC)[reply]
    - Sorry about not signing, I was trying to do a single edit and I guess I skipped one of them. I was referring to the "there was a consensus among knowledgeable editors" phrase. GSchizas (talk) 17:52, 6 July 2020 (UTC)[reply]
Transwiki somewhere. We shouldn't be replicating entire bodies of various works Wp:NOTREPOSITORY, but this would probably be helpful somewhere. Hog Farm _Bacon 19:53, 3 July 2020 (UTC)[reply]
- The WP:NOTREPOSITORY rule isn't relevant for these cases. These pages aren't mirrors or list of images etc. It's not even a "whole body of work". In most cases it's a reorganization of existing information under a common template and with a more readable form. GSchizas (talk) 22:06, 5 July 2020 (UTC)[reply]
Keep. At least keep until someone can successfully transwiki these pages and the template to Wikibooks (the last attempt was not successful). A mass deletion of these pages without a transwiki would be ~~against Wikipedia policy~~ a huge loss of information. I originally voted keep EBCDIC 037, EBCDIC 500, JEF, KEIS, and articles that are notable, and transwiki the articles that are not. Now I see that these pages are important to reflect code page history and contain valuable information, and should be kept on Wikipedia. Alexlatham96 (talk) 20:02, 3 July 2020 (UTC)[reply]

@Alexlatham96: Please avoid simply updating your discussion as you did at [1] (and possibly earlier). A minor spelling mistake is acceptable, sometimes striking and rewriting under a different timestamp works, or adding a new comment at the end may be apropriate. But changing content to which a person has replied can make that reply look out of context. Thankyou. Djm-leighpark (talk) 21:35, 29 July 2020 (UTC)[reply]

- What are the secondary sources for e.g. EBCDIC 037? The only non-IBM sources are this long list in which 037 is mentioned among many, many others, nothing more, and this technical mapping page. Neither of these give any indication of notability, and such pages exist for all these codepages, not just these. The exact same thing applies to e.g. EBCDIC 875 or EBCDIC 1026, none of these have any indication of notability. Fram (talk) 09:40, 6 July 2020 (UTC)[reply]
  - I found this newspaper explaining EBCDIC 037 (Code page 37). Code page 37 is explained in the February 15, 1988 edition of this newspaper, pages 22 to 24. Alexlatham96 (talk) 22:58, 6 July 2020 (UTC)[reply]
    - Thanks, but that's the internal university computing magazine. Such internal company or university sources are normally not considered for notability. Fram (talk) 07:42, 7 July 2020 (UTC)[reply]
Keep. The WP:INDISCRIMINATE and WP:NOTREPOSITORY rules don't really apply (I've replied to the other points separately). More to the point, I don't see how this attempt can end without removing ALL articles referring to code pages (and not just the EBCDIC ones). If that is the final goal, this (as was mentioned at the original AfD which was not resolved), this should be taken further up. In fact, most of the comments by Mark viking and DRMcCreedy apply to this AfD as well. In any case, even specifically for CP875 there are a few discussions about it in the Unicode mailing list, and I wouldn't be expecting anything much more glamorous than that; it's a very niche subject, so discussion in the Unicode consortium mailing list is the most you could hope for (at least in this century). Of course if the final decision is to delete all EBCDIC code pages (except a handful that seem to be the most US-centric ones in any case), there should be some automated or otherwise mass way to migrate these to a more appropriate sister site (I'm not entirely sure what the "transwiki" process entails). GSchizas (talk) 22:06, 5 July 2020 (UTC)[reply]
- If the best are "a few discussions in a mailing list", then that is a very good indication that these are indeed not notable at all. I only nominated the EBCDIC ones for now to give people a chance to get a look at them, to see if some are notable anyway (I'll take a closer look at the ones singled out above). If I had nominated even more articles at once, this would have been much harder and people would start complaining that I nominated too much at once. This is a damned if you do, damned if you don't case. Anyway, it is unclear what reason you give for keeping these, while at the same time confirming how extremely niche these things are, and how they thus lack all notability. Fram (talk) 09:32, 6 July 2020 (UTC)[reply]
  - It's not some random mailing list, it's the mailing list of the Unicode consortium. Out of those mailing lists the Unicode standard is eventually defined. No, I wouldn't expect there to be discussions about them in newspapers, but I think that's an unfairly high threshold to clear, for any article (not just Code page ones). Also note that for most of the EBCDIC code pages (and other code pages as well), they were created a long, long time ago, so it's not going to be easy to find a reference for each and every one of the EBCDIC codepages. That being said, just as long that the information contained in these pages is not lost somehow, I think an (automated) transwiki would serve. Making the articles with no other information than the list of characters marked as "stub" would also be a good idea. GSchizas (talk) 17:52, 6 July 2020 (UTC)[reply]
    - Keep. I see them as extensions of the EBCDIC article, which would be too long if it contained all of the information about each EBCDIC code page. I like the idea of marking articles as stubs if they don't contain enough detail. It allows other editors to eventually add information instead of the hurdle of creating the page from scratch. DRMcCreedy (talk) 18:51, 6 July 2020 (UTC)[reply]
      - But why would we need "all of the information about each EBCDIC code page" on enwiki? Of course this would make the main page too long, but that's not an excuse to keep subpages of minutiae. Tagging them as stub doesn't solve anything. Fram (talk) 07:42, 7 July 2020 (UTC)[reply]
Comment Just curious, why was this specific article selected to nominate the whole list of EBCDIC code pages? It seems a bit random to 'target' an article that's in the middle of the list! GSchizas (talk) 22:06, 5 July 2020 (UTC)[reply]
- In the category, it is the first one (the list is alphabetical, not numerical). Fram (talk) 09:32, 6 July 2020 (UTC)[reply]
  - Wouldn't that be Code page 259? GSchizas (talk) 17:52, 6 July 2020 (UTC)[reply]
    - Category:EBCDIC code pages is the one I'm talking about. Apparently some are ordered by full name, and some by number . I just followed the order of the category. Fram (talk) 07:01, 7 July 2020 (UTC)[reply]
Comment I'm still not seeing any evidence this passes GNG, the relevant notability guideline. What I'm seeing is WP:ILIKEIT excuses for why this should be exempt from notability. Reproducing all of the code pages would be WP:UNDUE at the main EBCDIC page, and stand-alone pages need to meet notability guidelines. This is the sort of thing WikiSource is for - the contents of documents that while they do have some interest, they do not meet the guidelines for getting their own article. Hog Farm _Bacon 14:00, 7 July 2020 (UTC)[reply]
- On the other hand, I see too liberal interpretations of the wikipedia rules. None of the mentioned rules apply here. Not WP:INDISCRIMINATE and WP:NOTREPOSITORY and certainly not WP:ILIKEIT or WP:UNDUE. I've explained the first two in another comment. Nobody here is claiming "I want this page to not be deleted because I like it". And I don't see how there can be any point of view (much less a non-neutral one) for such a page. As to the general notability, it is covered in other comments here; there has been discussion in independent media, and historically they affected current standards (such as Unicode). GSchizas (talk) 15:07, 7 July 2020 (UTC)[reply]
~~Delete~~ Speedy delete Any code page that doesn't have a specific claim of notability should additionally be made eligible for speedy deletion (not just the ones here). These don't meet GNG. PainProf (talk) 23:42, 7 July 2020 (UTC) - change vote to speedy delete, copyright infringement, likely not reprinted in many places because this code registry is copyrighted by IBM and is their intellectual property. PainProf (talk) 23:14, 10 July 2020 (UTC)[reply]
- Highly unlikely that the list of numbers, as opposed to the specific representation is (or can be) copyrighted. Also, the time for "speedy" delete has long, long, long passed (some of the articles are 10 years old or older). GSchizas (talk) 08:26, 13 July 2020 (UTC)[reply]
Transwiki it. The information is useful to somebody, but I don't think it belongs on Wikipedia.† Encyclopædius 12:13, 8 July 2020 (UTC)[reply]
Weak delete - I'm not going to move this mess of collections of trivia anywhere. Bearian (talk) 22:16, 9 July 2020 (UTC)[reply]
Strong Keep - I really hate to see these go, I would make the argument of WP:NSOFT where the topic of EBCDIC satisfies the notability guidelines and the list meets "It is the subject of multiple printed third-party manuals, instruction books, or reliable reviews, written by independent authors and published by independent publishers." As a software engineer I can say that I find these lists to be very notable. When I searched github and other source code repositories I find over 4 million references to EBCDIC. If I narrow my search down to just "IBM code page 875" I am finding thousands of projects using search terms such as CCSID 875, IBM-875, CODEPAGE_875, cptable_875, CP_875, CCSID875 and so forth. If you are reading this... please spend some time using those search terms to find references to "IBM code page 875". Am I the only engineer voting? DavidDelaune (talk) 00:08, 10 July 2020 (UTC)[reply]
- Maybe you can request to move these pages to your userspace if they are deleted or transwiki. However, I am not an admin. Alexlatham96 (talk) 03:06, 10 July 2020 (UTC)[reply]
- WP:NSOFT is an essay, not an accepted guideline, and it would never get accepted as a general guideline as it stands because it is so far removed from the WP:GNG. EVen then, being included in code or being mentioned is still not the same as "being the subject of multiple third-party manuals, instruction books or reliable reviews[...]", the subject should be the main topic, not something also mentioned. Oh, and EBCDIC itself is not up for deletion of course. Fram (talk) 08:22, 10 July 2020 (UTC)[reply]
Weak keep I don't buy that all of this meets WP:INDISCRIMINATE, while we are happy to keep truckloads of articles on sportspeople who have touched a football in an international game. Also, we appear to be having articles on all Unicode blocks (eg. Tamil_(Unicode_block)) sourced entirely to primary sources, though I am not sure how important EBCDIC is as compared to Unicode. SD0001 (talk) 09:59, 10 July 2020 (UTC)[reply]
- WP:OTHERSTUFFEXISTS, and please note that while others have given "indiscriminate" and other reasons to delete these, the original basic reason is a lack of notability, a lack of reliable independent sources for these pages. Whether they meet the letter of "indiscriminate" or not is hardly the point. Fram (talk) 10:18, 10 July 2020 (UTC)[reply]
  - From that same page: "When applied to creation of articles, this concept must demonstrate that articles of a similar nature and construct are included throughout Wikipedia.". There are of course easily proven notable specific pages for US-centric EBCDIC code pages, and there are articles for other non EBCDIC code pages. Is this a trojan-horse proposal to remove all of them? Again, they do have historical value, as they eventually influenced the creation of Unicode (among other things).GSchizas (talk) 19:57, 10 July 2020 (UTC)[reply]
Comment I think this discussion may be null and void, I just looked at one of the sources. In the top corner it clearly says copyright IBM. I don't think we can reproduce these sources in full. I think all of them are subject to copyright. I would suggest this material can't be included on Wikipedia and can only be linked to at IBM. PainProf (talk) 22:37, 10 July 2020 (UTC)[reply]

i.e. look at PDF linked here EBCDIC_1166 PainProf (talk) 22:45, 10 July 2020 (UTC)[reply]

So it's your contention that a chart showing Unicode characters that correspond to a different computer encoding is copyright infringement?! By that logic, every computer encoding table in Wikipedia will need to be deleted. IBM, Apple, Windows, Adobe, HP, DEC. All of them. If that's the case, we need a much bigger deletion discussion! But I don't agree with your assessment. The table at EBCDIC_1166 isn't a cut-and-paste of the cited reference. It contains Unicode characters and code point identifiers not in the cited source. DRMcCreedy (talk) 01:56, 11 July 2020 (UTC)[reply]

It's identical just transposed and including standard identifiers. There is no fair use exception that applies and IBM have a copyright notice clearly it is their contention that it is covered by copyright. Computer codes are covered by copyright and can't be directly reproduced without consent of the copyright holder. It is quite possible any encoding table not specifically released under a license requires deletion, regardless I've raised it as a copyright vio to check. Im not sure why this table would be exempt. The codes are their intellectual property. But let's see what they say. PainProf (talk) 02:46, 11 July 2020 (UTC)[reply]

I created many of these articles. I see sites like this and this showing these code pages. So I agree with DRMcCreedy. However, I will wait to see the result of the copyright investigation. Alexlatham96 (talk) 05:23, 11 July 2020 (UTC)[reply]

Unicode is the same: "You may freely use these code charts for personal or internal business uses only. You may not incorporate them either wholly or in part into any product or publication, or otherwise distribute them without express written permission from the Unicode Consortium. However, you may provide links to these charts." PainProf (talk) 14:35, 11 July 2020 (UTC)[reply]

The charts themselves aren't incorporated at all. The data that can be derived from the charts (or other sources) is a different thing than the specific representation. GSchizas (talk) 08:29, 13 July 2020 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: I had previously closed this AfD. After discussion on my talk page over concerns that this was not adequately advertised given how many articles were deleted I am relisting this for further discussion. Djm-leighpark who discussed it with me has other concerns but I will let them explain those for themselves.
Please add new comments below this notice. Thanks, Barkeep49 (talk) 21:04, 23 July 2020 (UTC)[reply]

Comment: @Thankyou Barkeep49. I had offered to look at this as a migrator(transwiki'er) of last resort however deletion of source articles occurred before standup of WikiBook was achieved. The key issue is, and I believe this is especially important when handling bulk work of several articles of one type, that discussion is undertaken with WikiProject to see if a solution can be agreed and a volunteer task group set up if not, which is in the spirit of WP:BEFORE Criteria#3. In terms of the (non consensus) closure of Wikipedia:Articles for deletion/EBCDIC 389 it is perhaps disappointing the recommendation was not to consult with WikiProject rather than suggest a bulk nomination. In any event the migration-and-stand-up failure of the EBCDIC code pages (at least up to this point) has caused a hiatus which should not have occurred, and indicates it was not totally trivial. It is often said AfD is not cleanup, and AfD is certainly not the place to plan a transwiki of this magnitude. There is a further problem that the issue of code pages other than EBCDIC have not been considered, so will we end up with the senario that half are on WikiBooks and half on WikiPedia which looks stupid. So there is a real case for considering all code pages rather than one and if presenting on WikiBooks how may they be best stood up. Understanding the totalilty of the problem also helps determine the level of automation that would be optimal for the whole job. As per a merge result from AfD its important at least one merge !voter is willing to undertake a (hopefully non-trivial merge). In this case I believe Mark Viking was the first transwiki !voter but to a degree indicated he was not was not intending to take on the job. In view of the non-success of standing up a WikiBook at this point transwiki !voters may need to consider their position. Thankyou. Djm-leighpark (talk) 21:56, 23 July 2020 (UTC)[reply]
Keep: At least until someone demonstrates a successful stand-up of ALL code pages in Wikibooks and improved guidelines for tranwikification. I didn't come to WikiPedia to script/automate ... and certainly not to do it rushed in the nice long days of summer while adjusting to new-normals while transitioning through lockdown states. WP:PRESERVE is mor ethe gist of thinking but it doesn't really cover transwiki, and that may not be the best option anyway. A template such as AwaitingPossibleWikiBooking might as be a compromise. Is there a rush? Djm-leighpark (talk) 22:20, 23 July 2020 (UTC)[reply]

Note: This discussion has been included in the list of Lists-related deletion discussions. Lightburst (talk) 22:58, 23 July 2020 (UTC)[reply]

FYI: Not all of the deleted articles were restored... I think the redirect pages are still gone, for example EBCDIC 1140. DRMcCreedy (talk) 03:52, 24 July 2020 (UTC)[reply]
Transwiki, with a preference for deletion if no suitable site can be found. I'm seeing a lot of "keep, I like it", "keep, other stuff exists", "keep, it's convenient" and "keep, transwiki is too hard" (??). What I'm not seeing is evidence of coverage that satisfies the GNG. – Teratix ₵ 04:03, 24 July 2020 (UTC)[reply]

On the contrary, I'm seeing a lot of "delete, I don't like it" and false calls to other irrelevant guidelines. The totality of the pages were called "trivia" or "minutia" (hence, "I don't like it"). There were also a couple of sources referenced here, but they were unfairly dismissed. No, you shouldn't expect a single code page to be mentioned in the front page of the Times; that's a quite unfair hurdle to overcome. GSchizas (talk) 08:50, 27 July 2020 (UTC)[reply]

I'm not seeing any sources mentioned that were not countered already by Fram's analysis. We're not asking for front-page newspaper coverage; all that's needed is a couple of independent, reliable sources that discuss the subject beyond a passing mention. – Teratix ₵ 12:12, 27 July 2020 (UTC)[reply]

Hence my comment "unfairly dismissed". GSchizas (talk) 10:55, 28 July 2020 (UTC)[reply]

Sorry, I'm unsure what you mean by that. Are you saying that Fram's comments were inaccurate, or that it's unfair to suggest these pages should satisfy the GNG? – Teratix ₵ 02:19, 29 July 2020 (UTC)[reply]

Note: This discussion has been included in the list of Computing-related deletion discussions. Djm-leighpark (talk) 19:57, 24 July 2020 (UTC)[reply]

Note: This discussion has been included in the list of Software-related deletion discussions. Djm-leighpark (talk) 19:57, 24 July 2020 (UTC)[reply]

Transwiki then delete. This is not content suitable for Wikipedia, but it would be a shame to just loose it. Do we have a bot that could just copy stuff like this to Wikibooks? Maybe someone should look into automating such process, to make it less cumbersome to save useful but unencyclopedic efforts like this. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:21, 25 July 2020 (UTC)[reply]

While per WP:TRANSWIKI there is a documented procedure for transwiki (Wikibooks seems to say dont do that manually!) there remains work to stand up the result in the target to make it usable. Its a bit like the plane taking you on your holiday getting to remote corner of the airfield - thats not a holdiay if you stay there - your need to get to the hotel and determine your baggage hs not been directed to Inishmurray or wherever and you're all set up to enjoy your holiday. In thw case of the first mentioned the results of the transwiki are here: [2]. This is some way off a completed curated WikiBook when removal of source is more appropriate and functionaility of source page(s) and target page(s) can be compared. This may or may not be hard but it will require some resource by someone to make it happen. For alternative views also see various sections on Barkeep49's talk page and maybe latest archive(?) and Wikipedia talk:WikiProject Computing#Articles for deletion. For a single page merge AfD result the actioner has probably a week to take the action, and a bit more if they give a good a reason. For a Transwiki to WikiBooks of multiple pages is is not unreasonable for the person standing up the wikibooks to have an appropriate amount of time. For me normally that might be a month, but currently its three and I'll negotiate with that with any designated WP:FUNKy person bar one if anyone thinks I'm being awkward or unreasonable. (In terms of codepages EBCDIC may be the tip of the iceberg and I'd like to know the extent of the iceberg first). Thankyou.Djm-leighpark (talk) 06:36, 25 July 2020 (UTC)[reply]

Keep - Does anyone think Code page should be deleted? I don't. These pages support Code page. Removing that support does not improve the encyclopedia. Merging all this to Code page does not improve the encyclopedia. There may be policy arguments for deleting all this but if it doesn't result in an improvement to the encyclopedia, I can't support that reading of the policy - WP:NORULES. ~Kvng (talk) 14:23, 27 July 2020 (UTC)[reply]
Transwiki and delete. This is not encyclopedic content. —David Eppstein (talk) 05:32, 28 July 2020 (UTC)[reply]
Comment: (Closer please note): This is currently likely heading for possible outcomes of No consensus or Transwiki. I am looking for signs any transwiki !voter who is prepared to champion into a WikiBook; preferably quickly; so WikiPedia users do not lose access to these code pages. As far as I know I am currently the only volunteer who in the event of a transwiki result, which I do not support, has offered to (try to) stand up in a WikiBook (pragmatically some scripting and maybe even regular expression capability is probably useful); but will only do so if the source pages are retained it situ until that is complete both due to assist in applying softlinks, cross checking the results, and also due to scripting and tooling assistance I might use. Thankyou.Djm-leighpark (talk) 07:05, 28 July 2020 (UTC)[reply]
Keep: I'd look at these as essentially part of the EBCDIC article (or other encodings for other similar pages), offering encyclopedic detail that would be awkward to fit into the main page due to length. I'm not aware of this being explicitly addressed in policy — but I do think it is implicitly supported by the documentation of standard practice (admittedly not policies) between WP:SIZESPLIT and WP:CONSPLIT(depending on how one reads it, see discussion below): note how CONSPLIT wants notability for the split topics, but such is distinctly absent from the practice documented under SIZESPLIT. I don't think WP:INDISCRIMINATE should (or is intended to, probably) discourage content that would be otherwise acceptable if not for being lengthy. —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 01:59, 29 July 2020 (UTC)[reply]
- Most important though is the text you didn't quote directly above the two sections you reference, in WP:WHENSPLIT: "Consideration must be given to size, notability and potential neutrality issues before proposing or carrying out a split." (bold in original). So notability clearly should be a consideration before a size split. So no, it isn't implicitly supported but explicitly, in bold, opposed. Fram (talk) 07:11, 29 July 2020 (UTC)[reply]
  - Mm, I guess. I read that as a summary of the following sections, with the notability point being inherited from CONSPLIT (but not SIZESPLIT), but can see how it can be taken as applying to both. Thanks for pointing that out. While it does give me some level of doubt about my interpretation, I still think I have to stick with the keep, even if only per the last sentence of my rationale. —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 21:50, 29 July 2020 (UTC)[reply]
Strong Keep. Please re-read the arguments of DavidDelaune. These code pages are a part of the foundation of computing. Doubtless there are thousands of sources for these code pages, they just aren't easy to find. I've read about them in countless programming magazines, manuals, and journals, but unfortunately, I've thrown them all away. Although it would be better if these pages were about the CCSIDs than code pages, this information is vital. These articles may never get lots of page views, but they are very useful extensions of the Code page article. Perhaps if one were to look for this information using the term CCSID or "coded character set id", they will change their opinion. If it were up to me, I would keep every one of them and move them all to 'CCSID nnn'.Jacona (talk) 12:28, 29 July 2020 (UTC)[reply]
Transwiki or delete Keep !voters have not been able to make any convincing argument that these pages are notable, which is necessary to keep them. (t · c) buidhe 22:45, 29 July 2020 (UTC)[reply]
Comment: I'd like to share a couple of recent comments from discussions at Wikibooks:Requests for Import. The first is that many imported materials have waited years for creation into a book (I assume in some sort of Limbo); the second it is unlikely anone on WikiBooks is likely to assist; thirdly I have indicated that the ultimate scope of the result on the basis of this being a precedent here may likely be applied to most of Template:Character encodings. People should also be aware Transwiki and delete is sated by import to the WikiBooks transwiki area which is pretty much a pathway to an unusable oubliette; I would say Transwiki and standup in WikiBook (in a reasonable timescale) and then delete (and delete if outside timescale). Thankyou.Djm-leighpark (talk) 23:02, 29 July 2020 (UTC)[reply]

As a practical matter, a transwiki result here will either leave stuff as it is or will (eventually) cause stuff to be deleted. It might help if Hog Farm, Mark viking, Encyclopædius, Teratix, David Eppstein and Piotrus clarified what they would like to see happen to the content until such time as it can be transwikified with appreciation that this may never happen. ~Kvng (talk) 22:43, 30 July 2020 (UTC)[reply]

Kvng, that clarification would be helpful. It should be noted that these page have actually been imported to Wikibooks already. The supporting templates would also need to be imported and they would then need to be assembled into a book. Best, Barkeep49 (talk) 22:48, 30 July 2020 (UTC)[reply]

If the outcome is transwiki and delete, but it is not transwikied in a reasonable time (say one week of closure) I think it should just be deleted, with the understanding that the content can be restored to user or draft space to anyone who proposes to actually carry out the transwiki. —David Eppstein (talk) 23:25, 30 July 2020 (UTC)[reply]

I suggested transwiki as an alternative to outright deletion for editors who would want to preserve this material. I am not one of those editors, but understand its value to some folks. I am sorry to see that the suggestion has led to stress and an extended AfD process. I think David's approach is a good one: get closure with this AfD, but provide a last chance for motivated editors to massage templates and complete the export to a usable wikibook. --{{u|Mark viking}} {Talk} 00:14, 31 July 2020 (UTC)[reply]

If "these page have actually been imported to Wikibooks already" (link please?) than I don't see what else we need to do outside deleting the stuff here? --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:33, 31 July 2020 (UTC)[reply]

Piotrus, [3]. I had closed this AfD as transwkify and delete. However, Djm-leighpark raised concerns that the AfD had not been adequately advertised given its scope so I reversed the close including restoring the pages here while further discussion occurred. Best, Barkeep49 (talk) 02:03, 31 July 2020 (UTC)[reply]

@David Eppstein I have very clearly volunteered to have a go and that is on the basis it remains in situ for up to 3 months as tooling I may use may do other stuff from original location. I have consideration of other code sets that may follow this one in this thinking. Remember on deleteion links to these pages get removed and caredifficult to re-establish even if stood up in draftspace. I have said one month would normally be sufficient and I was willing to give that explanation to a WP:FUnky person to a evaluation rather than outing by RL personal circumstancess here, suffice to say at the moment I have slept (sort of) on someone else' ssofa for the last 7 nights. Now an experienced Wikibooks person like yourself with the right skills might be able to stand up an EBCDIC WikiBook in hours. And if you (or anyone) are willing to do volunteer to do the job and document if for eveyone's benefit to show show unreasonably stupid and what I snail I am then you are welcome to do so. I have said I have have to have the articles templated to say an AfD has reached consensus and they are awaiting standind up in WikiBooks. Can I remind also folks this is a normination of 50+ pages and [[u|Bigdelboy}}(me) and/or Fram could follow this with one(s) of several depending on the result of this AfD. So, David Eppstein, are you volunteering to do the job (properly) or are you putting pressure and WP:Wikistress to organise my life around wikipedia? While Barkeep49 re-opened the AfD on the basis of lack of advertisment I had offered to assist as a volunteer of last resort, though knowning zitlch about transwiki or wikibooks. For those following my contribitions will see I have put some effort in two discussions as to how I would like to stand up Wikibooks ... though as a keep voter and a belief in the no-consensus result it is not appropriate for me to further a stand-up in Wikibooks until this is complete. To state the obvious if I am the only volunteer to stand up content in Wikibooks and a closer choses a transwiki and delete in a shorter timescale I would likely take to DRV. (An alternative would be to allow one month but on the basis I am permitted up to 2 one month extensions if requested provided I have shown some progress). Thankyou. Djm-leighpark (talk) 05:23, 31 July 2020 (UTC)[reply]

I appreciate Djm-leighpark's efforts to preserve and improve this content. If it helps, I support moving any affected articles to his userspace as user drafts, with no time limits for him to work on them. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 11:02, 31 July 2020 (UTC)[reply]

@Piotrus: I sincerely appreciate your thoughts on the userspace option, but I'll decline it. Some of the scripts I have in mind might be looking at inbound links to these pages. I'm looking at a requirement to create a book and possibly integrate when necessary. Everyone else sees individual pages. And I am also looking to provide continuous access to the information for potential users. I am very open to templating the pages in the interim by some prose such as "Determined by AfD to be unsuitable for WikiPedia discussion by retained for a short while to allow for project to transfer into a WikiBook". If I try this my way, I fail, and I apologise if that happens, and people will be rightful to mock. If I try it your way, and I fail, I risk I will mentally derange, and there I would be advised not to try. Thankyou.Djm-leighpark (talk) 11:38, 31 July 2020 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.