
= Contributing

Nice docs!: https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md

Say hello in the community: <https://www.talkyard.io/forum/>.

////
Good for you if you ask the people there what is currently being worked on, so you won't
accidentally re-implement something that's almost done already — people
might be working in their own work-in-progress topic branches that you
don't know about.
////



== Signing the CLA

You need to agree to link:./docs/CLA-v2.txt[this Contributor License Agreement] (CLA). You do that by
reading it (there's a human friendly intro) and appending a single line
paragraph with your real name (no pseudonyms) and the following text,
to all your Git commit messages: (note: a _Git commit message_ is not the same thing as a _GitHub comment_)

> I, Your Full Name <your@email.address>, agree to the Contributor License Agreement, docs/CLA-v2.txt.

Please squash your commits to just one (unless you're doing something that's easier
to review in separate commits).



== Translating

How to translate to a new language: link:translations/i18n-README.md[i18n-README], steps 1 and 2 only. — Open any translations pull request to the ty-translations repo: https://github.com/debiki/ty-translations.



== Refactoring


==== Ask first

Please ask the maintainers before you refactor something non-trivial,
because refactorings (incl automatic refactorings via an IDE)
sometimes result in huge diffs,
which could take "forever" for the maintainers to code review.
Then it's better if the maintainers do the refactorings themselves
— this can save time for them and for you: Tell them what they should refactor,
and wait, and they'll get it done for you.


==== Moving code to new files

If you move methods or a class to a new file, then,
when the Talkyard project maintainers review the diff,
it'll look as if new code has been added,
and as if all lines would need to be carefully reviewed
— when in fact old code was just moved elsewhere.

_This could cause the maintainers to reject the contribution_,
until you've made it simpler to code review,
by instead making the changes like so:

1) Copy the whole file to the new file. Commit.
2) Delete [the source code you want to move] from the old file.
   Delete [the code you do _not_ want to move] from the new file.
   Maybe rename any class in the new file.
3) Commit again.

Now the maintainers will see a copy file commit,
and a delete-lots-of-code commit. Both of which are quick to review.

