|
| 1 | +# Project scope and goals |
| 2 | + |
| 3 | +- This project contains blog posts that are published on the blog of Allegro, a high-tech company based in Poland. If the post mentions Allegro, the first |
| 4 | + use of the Allegro name should be in the form of the following link: `[Allegro](https://allegro.tech)`. |
| 5 | +- Blog posts are intended for technical audiences, such as software engineers, testers, UI designers, etc. Each reader may specialize in a different area, but |
| 6 | + general technical knowledge is expected. |
| 7 | +- The audience is international and may not be familiar with the Allegro brand or with Polish culture in general. If references to Allegro or other entities |
| 8 | + well known in Poland but not abroad appear, they should be explained. |
| 9 | + |
| 10 | +# Specific operations |
| 11 | + |
| 12 | +## Checking a blog post |
| 13 | + |
| 14 | +- When asked to "check" the document, "review" it, or to perform other similar actions, you must always follow the rules listed in this document and |
| 15 | + must include the following steps: |
| 16 | + - Check spelling and grammar |
| 17 | + - Check formatting |
| 18 | + - Check the content for compliance with the rules listed |
| 19 | + - Check the images (including image contents) for compliance with the rules listed |
| 20 | +- When checking the document, make the output as long as necessary to list all issues found. |
| 21 | +- Preserve word wrapping and line breaks in the original document. |
| 22 | +- Clearly mention when any of your hints are due to a specific rule listed in this document. For example if you suggest changing the spelling `colour` to |
| 23 | + `color`, mention that it is due to the rule about preferring American English. |
| 24 | + |
| 25 | +## Writing social media posts |
| 26 | + |
| 27 | +- When asked to write or suggest a social media post, follow these instructions exactly. |
| 28 | +- The blog post must pertain to a single blog post. If it is not clear which blog post you should work on, ask the user. |
| 29 | +- Follow these guidelines: |
| 30 | + - The input is a Jekyll page, consisting of front matter and markdown-formatted text. |
| 31 | + - Use the title of the blog post, taken from the front matter |
| 32 | + - Follow the title with the post's production URL in parentheses. It will be the same as the URL used to view the post locally, but with |
| 33 | + `https://blog.allegro.tech` as the base URL. |
| 34 | + - Avoid any markdown formatting, but you can use emojis sparingly where appropriate |
| 35 | + - The audience is programmer, testers, and other people working in IT. Assume basic understanding of IT and software engineering concepts. |
| 36 | + - Make it inviting to read the text |
| 37 | + - Use style which will be convincing to programmers and other geeks; avoid marketing style |
| 38 | + - Keep it direct and concise. Be factual and avoid exaggerations or excessive excitement. |
| 39 | + - Add up to a few hashtags matching the subject - use them either when using the appropriate word in the text or add them at the end if they don't fit the |
| 40 | + natural flow of the text |
| 41 | +- First, print an l1 heading saying "Social media post suggestions". Follow with a paragraph saying "These are only suggestions. Treat them as raw drafts. |
| 42 | + Review them carefully, and adapt contents and style to match the post's contents and your personal taste.". Then: |
| 43 | + - Create a short tweet suitable for Tweeter/X based on the blog post: |
| 44 | + - Precede it with an l2 heading saying "Tweet suggestion" |
| 45 | + - Stay within the length limit of 240 characters |
| 46 | + - Create a somewhat longer text suitable for Facebook or Instagram based on the blog post: |
| 47 | + - Precede it with an l2 heading saying "FB post suggestion" |
| 48 | + - Stay within the length limit of 2000 characters |
| 49 | + |
| 50 | +## Preparing a blog post for publication |
| 51 | + |
| 52 | +- When asked to prepare a post for publication, you must perform the following actions and only those actions (including smaller steps necessary to achieve |
| 53 | + these goals). Do not run any other checks or modifications unless explicitly told to: |
| 54 | + - Make sure you are working on a single blog post provided in your context. If it is not clear which blog post you should work on, suggest the latest blog |
| 55 | + post by date. |
| 56 | + - Run `scripts/prepare_publication/prepare_publication.py` with the blog post as the argument. Stop if the script ends with an error. |
| 57 | + - Run `bundle exec jekyll build` to ensure the blog post builds correctly. If it does not, print the error message and stop any further actions. |
| 58 | + - Ask the user if they want to view the blog post rendered after the modification. Print the question with a large, well-visible font. |
| 59 | + If they confirm, run `bundle exec jekyll serve` and inform the user about the URL where they can view the blog post. The base URL will be in the output |
| 60 | + of the command, printed before the command finishes - you have to capture the partial output. The URL path uses the <yyyy>/<MM>/<title>.html format. |
| 61 | + - Suggest social media posts for the blog post. |
| 62 | + |
| 63 | +# Project structure |
| 64 | + |
| 65 | +- The blog uses Jekyll, a static site generator. It is deployed to Github Pages, so only the subset of Jekyll that works in Github Pages should be used. |
| 66 | +- Blog posts are stored in separate Markdown files in the `_posts` directory. The file naming convention is `yyyy-MM-dd-title.md`, where `yyyy-MM-dd` is the |
| 67 | + date of publication and `title` is a slug (short, hyphen-separated version of the blog post title). |
| 68 | +- Images used in a single blog post named `yyyy-MM-dd-title.md` should be stored in the directory `assets/img/articles/yyyy-MM-dd-title/`. |
| 69 | +- Each author needs to be added to the `_data/members.yml` file, with their identifier (usually `firstname.lastname`), full name, a short bio, and |
| 70 | + optional links to their social media profiles. |
| 71 | +- For each author in `_data/members.yml`, a corresponding image should be placed in `assets/img/authors/` with the filename matching the author's identifier |
| 72 | + (usually `firstname.lastname.jpg`). |
| 73 | +- For each author in `_data/members.yml`, a directory names as the author's identifier (usually `firstname.lastname`) should be created in `authors/` |
| 74 | + directory. This directory should contain an `index.md` file with contents matching the template: |
| 75 | + --- |
| 76 | + layout: author |
| 77 | + author: firstname.lastname |
| 78 | + --- |
| 79 | +- A few static elements of the page exist, for example the "About us" page in `about/index.html`. |
| 80 | + |
| 81 | +# Rules for blog post contents |
| 82 | + |
| 83 | +## Language |
| 84 | + |
| 85 | +- All blog posts are written in English. Each blog post should consistently use either American English or British English and not mix the two. Prefer |
| 86 | + American English when in doubt. |
| 87 | +- Blog posts should use typographic quotes: `“”` and `‘’`, typographic apostrophes `’`, as well as em-dashes (`—`) where appropriate. Em-dashes should be |
| 88 | + surrounded by spaces on both sides. |
| 89 | +- The language should be clear and concise, but each author may use their own style. |
| 90 | + |
| 91 | +## Formatting |
| 92 | + |
| 93 | +- Blog posts may contain images. Use Markdown syntax for images without captions. If an image needs a caption, insert it as HTML following this template: |
| 94 | + <figure> |
| 95 | + <img alt="Alt text" src="/assets/img/articles/yyyy-MM-dd-title/short-image-name.jpg" /> |
| 96 | + <figcaption> |
| 97 | + Image caption, usually the same as alt text |
| 98 | + </figcaption> |
| 99 | + </figure> |
| 100 | +- The first paragraph of a blog post should not be preceded by any headers. |
| 101 | +- Headers should start at level 2. |
| 102 | + |
| 103 | +## Content |
| 104 | + |
| 105 | +- Blog posts may not reveal any confidential information about Allegro or its customers. Examples of confidential information include, but are not limited to: |
| 106 | + - Earnings, income, or any kind of financial information |
| 107 | + - Internal processes and tools |
| 108 | + - Technical information which makes it possible to infer confidential information. For example, the number of requests to a service may be confidential if |
| 109 | + it allows inferring the number of sales Allegro is making. |
| 110 | +- If any kind of confidential information appears in the post, print a clear warning that such information may probably not be published and advise the |
| 111 | + author to ask for help on #allegro-tech-blog Slack channel. |
| 112 | + |
| 113 | +## Images |
| 114 | + |
| 115 | +- If the blog post contains any images, their contents as well as alt-text and captions must conform to rules listed below: |
| 116 | + - Ask the author explicitly if they have permission to use for all images. Either the images must be created by the author, the auther must have been given |
| 117 | + explicit permission to use them, or they must be in the public domain or under a license that allows free use (ensure proper attribution in such case). |
| 118 | + - Analyze the content of the images and if it contains faces of any individuals (unless they are just small parts of a larger crowd), explicitly ask the |
| 119 | + author if they have permission to publish these faces. Suggest blurring out the faces if such permission is not present. |
| 120 | + - Print a warning if the image seems to be a diagram or a line drawing and has transparent background which may cause it to become hard to understand in dark |
| 121 | + mode. |
| 122 | + |
| 123 | +## Other |
| 124 | + |
| 125 | +Apply any other rules mentioned in `CONTRIBUTING.md` that are relevant to the task you are executing. |
0 commit comments