Various methuselahs are missing descriptions/censuses of their final patterns.

The various "category" templates (e.g. Template:OscillatorPeriod) all take differently-named parameters; this is confusing ("was it 't='? Or 'n='? Or 'c='? Or 's='? Or..."). Tweak all these to also (alternatively) accept a nameless parameter.

Template:GrowingSpaceship does not categorize (and thus has no supporting category infrastructure) based on the extra parameters, fs, bs, fp and bp.

Should it? Unlike with e.g. oscillators, it might well be that most of these categories would only contain one article, so there might be no point in having them.

The cellular automaton article currently only talks about CAs defined on a square lattice. This needs to change; there are CAs on all sorts of tilings, both regular (hexagonal, triangular) and less regular (Penrose, hyperbolic, ...). We're currently fudging hexagonal tilings by defining a "hexagonal neighborhood" on the square lattice (e.g. creating a "bricklayer's tiling"); but while that's fine (software such as Golly does hexagonal CAs this way), it's essentially an implementation detail. It should be noted, but CAs should be treated more generally.

Related: the article currently goes on at length about both CAs in general and Life-like CAs in particular. This needs to be disentangled, and Life-like CAs given their own article that introduces the basic concepts as required to understand them and otherwise refers to the general cellular automaton article.

Modify external link templates to all take title=, name=, pagename= and patternname= (as synonyms). It's not very useful for the parameters to have different names in different templates. (And some users even use entirely non-existent parameters without even so much as checking whether they do in fact have an effect.)

For that matter, saner external link templates in general. No hidden surprises, no things that don't work (but should), no inconsistencies, no making-the-user-jump-through-hoops-to-use-them, and so on. (See Template talk:LinkForumThread.) Also, cleaner template code that is more conducive to being edited and doesn't present itself as a thorny thicket of punctuation.

The last copy on archive.org dates from May 10, 2011, and lists 154 still lifes and oscillators, plus 4 spaceships. Images are broken, but the RLE encoded in the URLs can be used to identify (unnamed) patterns.

Make or consider making new pattern templates, along with the supporting template/category infrastructure for each, and use them where appropriate. Also add category links to Template:PatternMainNavbox ("minor types").

Check oscillator pages and ensure the infoboxes have rulemin and rulemax parameters.

Bit for cutting and pasting: |rulespecial=[[Conway's Game of Life|Conway Life]]|rulemin=B3/S23|rulemax=. But keep in mind some oscillators do in fact work in "lower" rules such as B3/S3 (clock) or B3/S2 (blinker, fox, killer toads, toad, traffic light).

Use Oscillizer to figure these out if not. Note that Oscillizer chokes on rule specs in S/B notation (e.g. 23/3); they have to be in B/S notation (e.g. B3/S23).

General ideas for LifeWiki

Would be nice to have better integration of RLE. Perhaps an extension to handle it, either in its own namespace (RLE:) or as parser tags (<rle>). Images could also be auto-generated from RLE then. Extension:EasyTimeline might serve as a base.

LifeViewer integration would also be nice, ideally tied into the above. See [10], [11].

Information on patterns etc. could additionally be encoded in a semantic format to facilitate automated processing. See [12]. Alternatively, would a Wikidata-like repo of facts be useful?

This could be done in Template:Pattern etc., and would be transparent to human users; articles would still render as before, and their source text wouldn't need to be changed.

What would be the best solution for this? Generating machine-readable data in some XML- or JSON-based microformat, Semantic Mediawiki, or a Wikidata-like repository?

Would be nice to handle other rules in some way.

How would articles be named? Prefixes/namespaces (e.g. HighLife:Bomber or B36/S23:Bomber)? Suffixes (e.g. Bomber (HighLife) or Bomber (B36/S23))? What about patterns that work in several important rules, such as the Moon (which is in both Seeds and Live Free or Die, not to mention various other B2 rules)?

How would pattern categories work? Different category trees for each rule?

Might be better to keep wikis for different rules separate (though they could share the same MediaWiki codebase, the way that the Wikimedia Foundation runs many different wikis). But this would lead to duplication of effort for templates etc. Would a central template repository be useful? (What if different wikis want to tweak the same template in different ways? The repo could act as a shadow repo only providing templates not present locally, but this would still mean templates would likely diverge instead of being edited globally.)

MediaWiki supports Lua scripting. Would be good to have, to replace the more complicated templates and to do things difficult to do with templates at all.

Combatting spam:

MediaWiki has various rate-limiting features etc. to combat spam. These could perhaps be used to do away with the "you manually have to request the trusted flag to edit" bit.

Alternatively, or in addition, it's possible to limit editing to auto-confirmed users.