add ppc cards from internal

external/ppc/add-gitignore/add-gitignore.md

+---
+layout: page
+permalink: /internal/ppc/add-gitignore/
+shortcut: ppc:add-gitignore
+redirect_from:
+  - /cards/ppc:add-gitignore
+  - /internal/cards/ppc:add-gitignore
+---
+
+# Add a .gitignore to your repository
+
+The version control system git tracks all files in a repository.
+
+Sometimes, you do not want certain files or directories to be tracked, but fully ignored by `git`. These files or directories
+can include binaries, images, dependencies, log files, or analysis results. Also, hidden system files are usually picked up by `git`.
+
+The idea is to create a file named `.gitignore` that lists all the files and directories that should be ignored by `git`.
+
+For instance, in order to ignore all log files with the suffix `.log`, the content of the `.gitignore` file should be:
+
+```
+*.log
+```
+
+A common example is to ignore system files as well, such as the `.DS_Store` file:
+
+```
+.DS_Store
+```
+
+*Note:* Sometimes, you might not see the hidden system files. You can do so by browsing to the directory in the terminal and typing:
+
+```bash
+$ ls -lash
+```
+
+Once the `.gitignore` file has been created, you can add and commit the file as any other file in the `git`-tracked repository. A relatively complete collection of `.gitignore` templates can be found [here](https://github.com/github/gitignore).
+
+More information on the `.gitignore` mechanism can be found [here](https://www.atlassian.com/git/tutorials/saving-changes/gitignore).

external/ppc/publish-repo/publish-repo.md

+---
+layout: page
+permalink: /internal/ppc/publish-repo/
+shortcut: ppc:publish-repo
+redirect_from:
+  - /cards/ppc:publish-repo
+  - /internal/cards/ppc:publish-repo
+---
+
+# Publish a repository
+
+By default, the repositories created on the LCSB Gitlab are private, i.e. they cannot be seen by anyone outside LCSB.
+
+In order to change the visibility of the repository, you can do so by browsing to `Settings` and then expanding the section on `Visibility, project features, permissions`.
+
+There, you can set the visibility to `Public`. It is important to note that the group must be public in order to change visibility of the repository.
+
+Remember to follow the [LCSB policy regarding code development](https://howto.lcsb.uni.lu/?policies:LCSB-POL-BIC-07). In case of questions, please do not hesitate to contact the [R3 team](mailto:lcsb-r3@uni.lu).
\ No newline at end of file

external/publication/10WaysImproveEnglish/10WaysImproveEnglish.md

+---
+layout: page
+permalink: /internal/publication/10WaysImproveEnglish/
+shortcut: publication:10WaysImproveEnglish
+redirect_from:
+  - /cards/publication:10WaysImproveEnglish
+  - /internal/cards/publication:10WaysImproveEnglish
+---
+# 10 ways to improve your English
+
+Francisco ARAGAON ARTACHO, former postdoc in the Systems Control group, has made a list of the ten most important points that helped to improve his English. In this article he shares them with you and explains what he means by each of them.
+
+**1. Believe improving your English is something very important**
+I think this is the most important point. If you don't believe a good written English is important, you will never improve it. So... why is it important? The way you write will give your reader a first impression about you. Even more, the reader will even get an impression about your personality (tidy / messy / arrogant / smart / knowledgeable / dumb). He / she probably doesn't know you, nor knows how good your ideas are. Don't give him / her a bad first impression: it will be hard to change his/her mind. While refereeing, I've directly rejected several papers because the English was terribly bad, or because it was full of typos. Nobody wants to read a text with many typos and which is clearly against the "golden rule" to never make a referee angry! Before submitting a paper / grant proposal, check it carefully. If one of your co-authors is a native English speaker, ask him / her to check the grammar of what you wrote. If not, ask a friend. If possible, wait for a week and read it again. You will probably discover that what you wrote is not as nice as you thought. You will find many typos and errors.
+
+**2. Read**
+Read as much texts in English as you can, especially novels. If you read good writers, perhaps (probably) something good will stick in your mind. Try to use their "fancy words and sentences" whenever it is possible.
+
+**3. Listen**
+I believe listening to music and watching movies / TV shows helped a lot to improve my English. Even during the most boring talk at a conference you may learn something good for your English.
+
+**4. Use synonyms**
+Synonyms are good. Avoid repeating words / structures whenever is possible. Use as many different sentence connectors as you can / know. Your text will look better and will be nicer to read. I normally use [Thesaurus](http://thesaurus.reference.com/).
+
+**5. Use a dictionary**
+While writing, I always have a dictionary open in my browser. I especially like [wordreference.com](http://www.wordreference.com/), which even has the British / American pronunciation for many words.
+
+**6. Check what Google says about your sentences**
+If you're not sure about a sentence you wrote, google it (or part of it), using quotation marks. If there are only a few hits, your sentence is probably wrong. If you doubt between two versions of the same sentence, the one with more results in Google is probably going to be the correct one.
+
+**7. Write short sentences**
+Long sentences make the reader feel exhausted, so do your best to avoid them. Try to punctuate correctly: use commas, colons, and semicolons.
+
+**8. Write short paragraphs**
+In a similar way to the previous point, long paragraphs are exhausting. I remember that when I was a kid I hated books without "white space" (breaks), and I guess I still have some similar feeling. A text with short paragraphs always looks easier to read at first glance. Additionally, while aiming to write short paragraphs, you will be forced to structure your ideas (next point).
+
+**9. Structure your thoughts through the text**
+Structure your ideas to explain yourself. It is very important to use sentence connectors, as for example: moreover, however, besides, although, nevertheless, in spite of, then, therefore, thus, hence, whence, on one hand / on the other hand, additionally, further, furthermore, otherwise...
+
+**10. Ask people to correct you**
+People (wrongly) believe that it is impolite to correct others when they're not speaking in their native language. I guess this happens because no one likes to be wrong, and even less to be pointed out for being wrong. At the beginning, when I started learning English, people used to correct me very often. Unfortunately, as soon as my English was "good enough", I noticed that I was getting less and less corrections, despite my English wasn't that good. For example, only last year my Aussie housemate told me that I was pronouncing "yellow" wrong (and, probably, every single word starting with "y" - pronouncing it like "j" in "jelly") because he wanted to piss me off. At that moment I guess he was disappointed to see that I liked to be corrected, but he started telling me my mistakes since then. Thus, if you want to be corrected you'll need to ask the others to do it, and remember to thank them with a not-very-fake-looking smile when they do it :).
+

external/publication/publishInBiotools/publishInBiotools.md

+---
+layout: page
+permalink: /internal/publication/publishInBiotools/
+shortcut: publication:publishInBiotools
+redirect_from:
+  - /cards/publication:publishInBiotools
+  - /internal/cards/publication:publishInBiotools
+---
+
+# Publishing a tool in *bio.tools*
+
+First, *bio.tools* serve two main purposes:
+
+- dissemination of your tools
+- collecting systematic and reasonable statistics about the available
+  software for many purposes, including data science and performance reports
+
+To get your contents in, you need to fill an application and get an account.
+Filling out the application is particularly straightforward.
+
+After you get the account, you can click "Add content" in the "Menu" on the top
+right, then go through around 10 tabs that allow you to fill lots of
+interesting information about your tool, and finally submit it, which makes the
+contents immediately visible.
+
+This card collects some reminders about what you should not forget while
+submitting the tool, perhaps useful as a checklist.
+
+## General tips
+
+### Use search and consult the curation guide to resolve ambiguities
+
+The guide is currently here:
+https://biotools.readthedocs.io/en/latest/curators_guide.html#summary-group
+
+It includes helpful and authoritative guidelines for almost all fields that you
+can fill, including examples.
+
+As the last resort when you do not know what to do with a field, you can try
+search suggestions in the structured search box above, and try to be at least
+consistent with the rest of the database. In the search box, type in a single
+letter, wait for a moment (or press arrow down), choose the annotation
+category, and see what others have used.
+
+### Add a "backup" maintainer
+
+This may remove a lot of unnecessary workload from you, and will help everyone
+at times when you are not available. (Or, at least, reduce the stress levels.)
+
+### Add _many_ links to all types of documentation
+
+This helps in two ways:
+- The search engines will be able to categorize and index your contents better,
+  possibly giving more helpful links to your tools.
+- Users of *bio.tools* will be able to explore the most relevant parts of your
+  documentation very quickly, helping them to make a faster decision about
+  using your tool. For example, it is often a relief to quickly see that a
+  bioinformatics tool has an explicit step-by-step tutorial, and that a web
+  visualization framework has a complete useful API reference.
+
+Include the (interesting) relations to other tools. This adds a bit more
+interesting data to both search engines and statisticians who process
+*bio.tools* content, and gives an documentation of possible "use-cases".
+
+## Proper labeling
+
+### Choose the bio.tools ID correctly
+
+As the name says, the "Persistent biotoolsID" cannot be changed. It will be
+permanently displayed as an identifier in almost all content that is
+autogenerated from *bio.tools*. For users, that concerns mainly the URLs, so
+you may want to apply similar formatting guidelines as for URLs (use hyphens
+`-` instead of underscores `_`, do not use capital letters, ...).
+
+### Add your tool to proper collections
+
+Collections group the results of various larger cooperated (or loosely
+organized) efforts, such as "Galaxy tools", "Parkinson disease research", and
+"3D BioInfo".
+
+If your tool is related to ELIXIR, you should fill in the correct ELIXIR node,
+platform, community _and_ collection. Remember to:
+
+- Add _all_ involved ELIXIR nodes.
+- **Add your tool to the node-specific ELIXIR collections.** For LCSB, that is
+  usually **ELIXIR-LU**. This is counter-intuitive and seems duplicate to the
+  categorization by ELIXIR nodes, but:
+  - at least 2 nodes use collections labels instead of node labels to scrape
+    data about their tools
+  - there is search support only for the collections; currently (March 2021) it
+    seems that you cannot easily search for tools by ELIXIR nodes
+
+### Fill in the tool "Function" very verbosely
+
+The main reason for categorizing tool functions is to provide a systematic way
+for listing the tools in topic-based catalogues that can be browsed by users.
+
+The categories and data formats available for describing your tool function
+rarely give a precise match. That is okay, you can choose a broader category.
+
+Use all categories that match even a small part of your tool; it will
+potentially help *bio.tools* users to find your tool even if they do not know
+what precisely they are searching for.
+
+Selecting a very specific category ("deeper" in the topic tree) also implies
+all "parent" categories, so you do not have to be afraid of over-specification.
+*Bio.tools* search box will automatically include your tool in searches for the
+broader categories.
+
+## References and publications
+
+### Be comprehensive about publications
+
+Add _all_ publications where you described, showcased, and benchmarked the
+tool. Also add preprints.
+
+There are several purposes for the precise publication tracking:
+- the users may (and often will) sort the tools by the citation count, likely
+  trying the most tested approach first
+- the publications provide an additional form of documentation (often more
+  colorful than the API docs)
+- the links and citation counts provide a nice, easily available statistic
+  about ELIXIR performance
+
+### Use the Credit tab
+
+The purpose of the "Credit" tab is not immediately obvious -- basically, you
+can credit anything that has helped you with creating the tool. This is
+currently used for at least 3 purposes:
+
+- systematic tracking of non-ELIXIR collaborators (add ORCIDs)
+- listing the **industry partners**
+- listing affiliations to particular research institutions
+  (**remember to add LCSB**)