Tips for Creating/Maintaining a Golfing Language Creating a golfing language can be hard. Let's help budding golfing language creators out and provide some helpful tips on how to create one.

I'm looking for tips on:


The design process
Implementation 
Community engagement 


One tip per answer would be appreciated, and tips like "don't create a new language, use an existing one" probably aren't very helpful.

You don't need to have created a golfing language to answer this question. Feel free to answer from personal experiences or from general observations.
Here are some suggestions. Sorry that this partially overlaps with other answers, which have been posted as I was writing this.
Design process

One possibility (by all means not the only one) to decide which features (functions, data types, etc.) your language L should have is to base it on another language B that you have been using for long. That way you already have a good idea which functions of B are used most often, and therefore should be included in your language L, and you can assign shorter names in L to functions that are commonly used in B.

Examples:

L = MATL: B = MATLAB/Octave.
L = Pyth: B = Python.
L = Japt: B = JavaScript.
L = Brachylog: B = Prolog.
L = Husk: B = Haskell.
L = ShortC: B = C.
L = V: B = Vim.


Decide which &quot;paradigm&quot; your language will use. Some examples are


Stack-based (Cjam, MATL, 05AB1E);
Tacit (Jelly);
Prefix notation (Pyth);
Infix notation (Pip, Japt);
Fixed arity (Pyth);
Variable arity (CJam, MATL, Japt).

These decisions are quite independent from item 1. For example, MATL's function f has the same functionality as MATLAB's find, but is used differently in that it pops its inputs from the stack and pushes its outputs onto it, whereas MATLAB uses normal function arguments which can be stored in variables.

Incorporate functions from other golfing languages that you find useful. Don't let item 1 (if applicable) limit language L's definition.

Be prepared to add functions in the future. As you (or others) use the language, you will find things it would be nice to add. So reserve some of the &quot;namespace&quot; for future expansion. For example, don't use up all your single-character names at once.


Implementation

Write the compiler (or interpreter) for your language L in a language C that you know well (often C = B).
The compiler is most often actually a transpiler into another language T (which can be the same as B or C). Language T should have a free implementation. That way it is viable to have an online compiler for your language. The compiler will be a program in C that takes source code in L to produce transpiled code in T, and then calls T's compiler/interpreter to run the transpiled code.

A natural choice is C = T. Examples:

L = Japt: B = C = T = JavaScript.
L = Jelly: C = T = Python (and Jelly is inspired by J; but perhaps not so much as to claim that B = J).
L = MATL: B = C = T = MATLAB/Octave.

Community engagement

Host your compiler/interpreter in a public repository such as GitHub, so people can easily download it, create bug reports, suggest new features or even contribute with code.
Write good documentation. That helps users understand your language better. Besides, I found that task more rewarding than I expected. I recommend writing the specification while you are designing the language, not at the end. That way consistency between language behaviour and its specification is ensured.
Ideally the documentation should include some quick reference (table or summary), so experienced users don't have to go to the full documentation simply because they have forgotten the name or the syntax of a function they know.
Create an esolangs page with basic information about your language.
Create a chat room where people can ask and discuss about the language. Visit it often.
Answer questions in your language, with explanations about how the code works. You'll want to do that anyway (it's your language, you will find it fun to use), but this also helps get people curious about your language, and shows some of the language's properties, which might get people interested.
If you chose to base your language L on a language B (see item 1) that is general-purpose and well known, users of B will find it easy to switch to L, which will allow them to provide short answers (in L) with minimal effort (coming from B).