[WIP] Decluttering

[AlexDaniel]

This ticket is for my personal list of things that can be simplified. For each list item a separate ticket will be filed (if the change is worth it), so please refrain from discussing specific items here. That said, feel free to recommend other things that can be added to the list. Currently the goal is to write down everything I notice, with no real plan to actually do any changes, so don't worry!

• Language
  • notandthen – from the docs: “At first glance, notandthen might appear to be the same thing as the orelse operator. The difference is subtle […]. […] The notandthen operator is a close relative of without statement modifier, and some compilers compile without to notandthen”. Used 0 times in the ecosystem.
  • Release names – next 6.e release should have “e” which stands for nothing, because enough.
  • Letters in versions – why? Semantic versioning, anyone?
  • “roast” as a name – rename it to perl6-spec
  • perl6/spec repo – should be renamed to perl6/old-design-docs
  • “POD6” as a name, come up with something explicit à la javadoc
  • POD6 itself – make it markdown-compatible or something?
  • Naming thing
  • module vs package – do these have to be different?
  • nodemap, deepmap, duckmap – do we need all of them?
  • “utf8-c8” – can be renamed to something readable like “utf8-raw”
  • AdHoc exceptions – upgrade to proper exception classes
  • exceptions in general – some clean up is needed
  • roast directory structure is not useful – Names of test folders roast#357
  • underscores in method names – MOP ^add_method could be renamed as ^add-method rakudo/rakudo#1292
  • P5 regexes – Remove P5 regexes from Raku #133
• Rakudo
  • Release numbers – meaningless and don't play well with point releases
  • $*PERL.compiler.release-number and $*PERL.compiler.codename – currently not set, should be removed?
  • Release codenames – done years ago by somebody else! Awesome! Keep an eye on other unnecessary naming
  • Separate github org – no measurable gain but difficulties with moving the tickets and giving access to contributors (see Moving tickets between rakudo and problem-solving repos is impossible #46)
  • CLA – what's the point? (log, log, log)
  • nom branch – done a long time ago! Keep an eye for similar issues so that it doesn't happen
    again.
  • “NQP” as a name – newcomers often get confused as to what it is, maybe it needs less sexier name (something like rakudo-middleware but better)
  • Flappers – find a way to document them all and plan how to get rid of them eventually, then remove all flapper-related logic (e.g. from releasable)
  • Perl class methods (DISTROnames, KERNELnames, VMnames) – what's up with these names?
  • Rakudo on JVM is not actively developed, should we keep maintaining it?
• MoarVM
  • Separate github org – no measurable gain but difficulties with moving the tickets (see Moving tickets between rakudo and problem-solving repos is impossible #46)
• Infrastructure
  • Bots that are not part of whateverable – they usually have no tests, worse error reporting, less consistency with other bots, missing features (like bot name autocorrect), etc. for no good reason. Just move them into whateverable repo with little tweaks
  • RT – Some attempts were made but then it all happened by itself. Keep an eye on other nontraditional tooling and try to move on with the times (or be slightly ahead, it's less painful this way!)
  • Transfer all @LARRY tickets to problem-solving
  • Unify some repositories into problem-solving. Currently only https://github.com/perl6/user-experience/ comes to mind. Also https://github.com/perl6/infrastructure-doc
  • Remove junk repos from perl6/ org
  • Move modules from perl6/ org to https://github.com/perl6-community-modules
• Community
  • …
• Modules
  • Fix modules that have no license: Modules which have no license field or non-standard values for "license" ecosystem#324
• Other
  • Abandoned tickets and PRs in all repos (e.g. There's a huge PR/issue deficit in the Rakudo repo #5)
  • All files in main repositories that still have _ in their names
  • All .pm and .pl files
  • Documentation files are a mess – some are .pod6, some are markdown, some are asciidoc, some are pod5.
  • Trailing whitespace – people say that removing it in one go pollutes git blame, but in reality people keep removing whitespace in many unrelated commits which is much worse. Related things:
    • File permissions
    • Line endings
    • Trailing newlines
  • Review and consistify permissions to all repos
  • Delete unnecessary github teams
• Periodical
  • Open branches – Review open branches? rakudo/rakudo#3039 Review open branches? nqp#563 Review open branches? MoarVM/MoarVM#1135
  • Ecosystem unbitrot – https://github.com/perl6/ecosystem-unbitrot/issues
• …

[JJ]

How can you make Pod6 (or whichever) markdown-compatible? You mean ditching Pod6 and having a new perl6 braid that uses markdown instead of Pod6?

[AlexDaniel]

@JJ yeah, that's a bit closer to what I meant. But this ticket is mostly for brainstorming, I don't have any strict plans so far. Eventually I'll start filing separate tickets with more info.

[coke]

More CLA Info: https://www.perlfoundation.org/license-faq.html

[AlexDaniel]

This ticket was just a collection of loosely related issues, where each issue wasn't really significant by itself but all issues together create a feeling of mess and lack of coordination. The main point was to create a sort of mindset that would allow us to move into a different direction (actively wanting to make things easier and reduce bitrot, instead of letting everything accumulate in an unrestricted way). I got a lot of resistance when working on any of these, and the ones that got fully resolved were due to series of lucky events and coincidences. Again, I don't think I motivated anyone to do anything, or ever managed to change someone's mind, so maybe the next person will have better luck.