You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/writing/blog-posts/blog-posts.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ Writing a blog post can be intimidating at first, but it's easier than you think
4
4
5
5
## Step 1 - Identify a topic
6
6
7
-
To get started with writing on the blog post, first, you need to identify a suitable topic, the topic can be pretty general for a start and could range from general topics relating to technologies in Mindee, Mindee specific topics, problem-solving topics etc. For example
7
+
To get started with writing on the blog post, first, you need to identify a suitable topic, the topic can be pretty general for a start and could range from general topics relating to technologies in Mindee, Mindee specific topics, problem-solving topics, etc. For example
8
8
9
9
- How to automatically add Payslips to Google Sheets using Mindee.
10
10
- How to Convert Paper Documents into Database Records (with Examples).
@@ -13,21 +13,21 @@ If you're having trouble coming up with topic ideas, a good topic brainstorming
13
13
14
14
## Step 2 - Create the outline
15
15
16
-
Organize your content in an outline by creating a table of content and breaking your ideas into sections. Also, add a concluding paragraph at the end of your article. For example
16
+
Organize your content in an outline by creating a table of contents and breaking your ideas into sections. Also, add a concluding paragraph at the end of your article. For example
17
17
18
18
- Introduction
19
19
- What is Mindee
20
20
- Who uses Mindee
21
21
- How can Mindee improve workflow
22
22
- Conclusion
23
23
24
-
You’ll also need a feature image: the main image which represent the topic, or in cases where it's difficult, something related to embelish the article. The image will be used on the front page, and as the hero image on your blog post. The size needs to be around 2:1 (twice larger than the height) to fit our WordPress template. You need to have the right to use the image in a commercial setup. Here's [some places](../../../resources/misc.md#pictures--images) where you can find free and commercialy usuable images.
24
+
You’ll also need a feature image: the main image which represents the topic, or in cases where it's difficult, something related to embellish the article. The image will be used on the front page, and as the hero image on your blog post. The size needs to be around 2:1 (twice larger than the height) to fit our WordPress template. You need to have the right to use the image in a commercial setup. Here are [some places](../../../resources/misc.md#pictures--images) where you can find free and commercially usable images.
25
25
26
26
## Step 3 - Write the Introduction
27
27
28
28
Write an intro (and make it captivating). Describe the goal of your article and how it will answer an issue that the reader may be having. This will entice the reader to keep reading by demonstrating how the content will benefit them at work and improve efficiency.
29
29
30
-
To do that, please create a Google Doc in the [blog folder](https://drive.google.com/drive/u/2/folders/1syUDM_hb-mmX39nYLopTgQlvRLYpGpRh) on Google Drive (if you don't have access, let Fred knows). You can now use Markdown to write in Google Doc by activating it once by checking the `Automatically detect Markdown` in the `Tools -> Preferences` menu on the `General` tab. Unfortunately it does not support inline code or code block, so to format your code, just format your code using the `Roboto Mono` font.
30
+
To do that, please create a Google Doc in the [blog folder](https://drive.google.com/drive/u/2/folders/1syUDM_hb-mmX39nYLopTgQlvRLYpGpRh) on Google Drive (if you don't have access, let Fred knows). You can now use Markdown to write in Google Doc by activating it once by checking the `Automatically detect Markdown` in the `Tools -> Preferences` menu on the `General` tab. Unfortunately, it does not support inline code or code blocks, so to format your code, just format your code using the `Roboto Mono` font.
31
31
32
32
## Step 4 - Complete the Article
33
33
@@ -37,7 +37,7 @@ We are looking forward to this and are excited to read what you write!!!
37
37
38
38
### Step 5 - Review of your Article with the Developer Relations' Team
39
39
40
-
Once ready, please notify Fred on Slack. The process will go as follow:
40
+
Once ready, please notify Fred on Slack. The process will go as follows:
41
41
42
42
1. Favour will review your article as soon as possible, making suggestions and adding comments if needed.
43
43
2. Once it's done, she will notify you and you will need to review her suggestions (accept or refuse text changes) and comments. This back and forth between you and Favour will go as long as all suggestions and comments are resolved.
@@ -49,9 +49,9 @@ If you have any questions, or need help, feel free to add a comment in the docum
49
49
50
50
## Step 6 - Publication
51
51
52
-
Once the review process is complete, your article is ready to be published. Keep in mind that it does not mean it will be done right away. We are trying to schedule publications in a regular schedule and not overwhelme our community with too many publications in the same week. At that stage, Favour will convert your article from Google Docs to our WordPress blog. She will ensure that everything is ready for us to publish when the time will be.
52
+
Once the review process is complete, your article is ready to be published. Keep in mind that it does not mean it will be done right away. We are trying to schedule publications in a regular schedule and not overwhelm our community with too many publications in the same week. At that stage, Favour will convert your article from Google Docs to our WordPress blog. She will ensure that everything is ready for us to publish when the time right.
53
53
54
-
The day of the publication, we will share your content on multiples places:
54
+
The day of the publication, we will share your content on multiple places:
55
55
56
56
- On our internal Slack, in the #shakespeare channel;
57
57
- In our community Slack, in the #general channel;
Copy file name to clipboardExpand all lines: content/writing/documentation.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,7 +71,7 @@ Not sure how and why, but sometimes the `Page History` will display the wrong na
71
71
72
72
README.io doesn't provide automatic redirection when page `slug` changes. If you do, you need to manually add a redirection rule in the Error Page.
73
73
74
-
### Suggest Additionnal Edits
74
+
### Suggest Additional Edits
75
75
76
76
In the case of a back and forth between the person who suggested some documentation edit, and one of the reviewer, please limit these interactions to once or twice. If there are too many back and forth, README.io just stop working and prevent us from merging the changes. README.io isn't built for that: see [Large Suggest Edits section](#large-suggest-edits) for more details.
Copy file name to clipboardExpand all lines: content/writing/markdown.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ Here is an example of how you can write a callout:
28
28
```markdown
29
29
> 📘 **Info**
30
30
>
31
-
> Vitae reprehenderit at aliquid error voluptates eum dignissimos.
31
+
> This is an example of a callout.
32
32
```
33
33
34
34
### Types
@@ -38,19 +38,19 @@ There are four different types of callouts we use: `success`, `info`, `warning`,
38
38
<!-- markdownlint-disable MD028 -->
39
39
> 👍 **Success**
40
40
>
41
-
> Vitae reprehenderit at aliquid error voluptates eum dignissimos.
41
+
> This is an example of a callout.
42
42
43
43
> 📘 **Info**
44
44
>
45
-
> Vitae reprehenderit at aliquid error voluptates eum dignissimos.
45
+
> This is an example of a callout.
46
46
47
47
> 🚧 **Warning**
48
48
>
49
-
> Vitae reprehenderit at aliquid error voluptates eum dignissimos.
49
+
> This is an example of a callout.
50
50
51
51
> ❗ **Error**
52
52
>
53
-
> Vitae reprehenderit at aliquid error voluptates eum dignissimos.
53
+
> This is an example of a callout.
54
54
<!-- markdownlint-restore -->
55
55
56
56
## Code Block
@@ -87,7 +87,7 @@ Write in such a way that someone could totally understand without needing images
87
87
-**Bad**: picture of a monkey
88
88
-**Good**: a monkey eating a banana
89
89
90
-
2. For screenshot, focus on what we want to show on the image, not everything, for example: a screenshoot of the signup page where we want the user to see which checkbox to check could be something like _“the terms and services checkbox under the password textfield”_.
90
+
2. For screenshot, focus on what we want to show on the image, not everything, for example: a screenshot of the signup page where we want the user to see which checkbox to check could be something like _“the terms and services checkbox under the password text field”_.
91
91
3. For diagram or anything with data, a quick summary, like a caption, with something that points to a summary of the data: not all details, but enough for someone to understand.
92
92
<!-- markdownlint-restore -->
93
93
@@ -135,7 +135,7 @@ The second way is more easy to manage when you have to reorder your list, but to
135
135
136
136
## Table of Content
137
137
138
-
Some Markdown parser will gebnerate a table of content (toc) automatically for you (i.e GitHub), but you should always write them manually. There is no guarantee that your content will be viewed with a tool that will do the same.
138
+
Some Markdown parser will generate a table of content (toc) automatically for you (i.e GitHub), but you should always write them manually. There is no guarantee that your content will be viewed with a tool that will do the same.
Copy file name to clipboardExpand all lines: jobs/career/technical-writer.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,7 +54,7 @@ At this point, one is helping others be the best that they can be, removing them
54
54
- Develops proven systems and approaches to technical writing. Replicates those systems and approaches across the team so that others may learn from and improve on them.
55
55
- Mentors and actively drives the technical skills of the immediate or extended team.
56
56
- Anticipates issues or implications that their ideas would have on others, and pursues mutually beneficial strategies.
57
-
- Anticipates the needs of those around them. Is respectful in terms of async hygiene, exhibiting care that their teammates can get in touch with them or knows their status during working hours. Fills out process docs without having to be asked.
57
+
- Anticipates the needs of those around them. Is respectful in terms of asynchronous hygiene, exhibiting care that their teammates can get in touch with them or knows their status during working hours. Fills out process docs without having to be asked.
58
58
- Works to refine team processes to ensure everyone can be as productive as possible and build cohesion within the team.
59
59
- Considers team morale one of their initiatives- actively strives to support others, make sure their voices are heard, and illuminate others’ work.
Copy file name to clipboardExpand all lines: jobs/interviews/technical-writer.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@
8
8
- Nothing is set in stone. No voice & tone document. No detailed process. We are a startup.
9
9
- What I'm looking for is someone eager to learn, who have a high attention to details (links in your resume, some links or spaces/break lines missing in your articles...), and can be somewhat autonomous.
10
10
- What is your process to write about a technology you don't know yet?
11
-
- How do you come up with the topics yourwant to write about on your blog?
11
+
- How do you come up with the topics you want to write about on your blog?
12
12
- Did you read our documentation? What would you improve?
13
13
- If there's a new feature coming out soon that you don't have time to finish documenting, is it better to publish no docs or partial docs? Why?
14
14
- Imagine that, by some miracle, there's nothing in the queue. No releases, no projects. What do you do?
0 commit comments