Feedback & Complaint Guidelines
Promise
After this page you can send feedback or a complaint about sourovdeb.com in a way that gets a useful answer, and you know what happens after you send it.
Audience: Readers and teachers in Réunion (French first language), plain English A2–B1. Context: using a website and asking for a correction.
Time to read: 6 minutes · Format: web page
Before you start
You will be able to: write a short, specific message with the right subject line and send it by the right channel
Three words you need first:
- feedback — your opinion or report about a page or the site.
- bug — a technical problem, for example a broken link.
- reproduce — to repeat the steps so someone else sees the same problem.
You need: a device, the page address, and about five minutes.
Thank you for taking the time to share your thoughts. This document outlines how to provide feedback, report issues, or lodge complaints in a way that leads to the best possible resolution. (my original words, unchanged)
Segment 1 — Four kinds of feedback you can send
I welcome four kinds. For each one, please add one useful detail.
Visual 1 — Comparison table
What it shows: four types and what to include.
How to draw it: Draw a table with two columns: type, and what to add.
The point it makes obvious: Each type needs a different detail.
TYPE ADD THIS
------------------- ----------------------------
Content quality the section + what was unclear
Technical issue screenshot + browser/device
+ steps to reproduce
Topic suggestion your teaching context + need
User experience what you expected vs what
happened
Examples from the original page: Content quality: factual errors or outdated information; unclear explanations; missing context. Technical: broken links; page layout problems; slow loading or accessibility issues. Topic suggestions: specific teaching techniques, lesson ideas or ELT tools. User experience: confusing navigation; mobile problems; search not working.
Check 1: What should you add to a technical report?
Show the answer
Next: where to send it.
Segment 2 — Three ways to send it
Option A — Email. To: sourovdeb@zohomail.com. Start the subject line with [FEEDBACK], [BUG] or [SUGGESTION]. Best for detailed issues and privacy concerns.
Option B — GitHub Issues. github.com/sourovdeb/wordpress-control/issues. Best for technical bugs, feature requests and tool issues. Use the template and include steps to reproduce.
Option C — Direct message (Twitter/LinkedIn). Best for quick questions and non-urgent feedback. Response time may be slower.
Visual 2 — Flow diagram
What it shows: which channel to choose.
How to draw it: Draw a question and three branches.
The point it makes obvious: Match the channel to the size and privacy of your message.
What is your message? | +-- detailed or private --> Email +-- a bug or a feature --> GitHub Issues +-- quick, not urgent ----> Direct message
EXAMPLE (work): You find a broken link in a lesson and want to send a screenshot: use email with [BUG] in the subject.
Check 2: Which channel is best for a private concern?
Show the answer
What does a good message look like?
Segment 3 — Unhelpful and helpful messages
Here are four pairs. Read the left side, then the right side.
Visual 3 — Before / after pair
What it shows: four vague messages rewritten.
How to draw it: Write the vague message on the left and the clear one on the right.
The point it makes obvious: A helpful message names the place, the problem and what you want.
UNHELPFUL HELPFUL
"This post is bad" "The example in section 2.3
contradicts the lesson plan
format you described earlier.
Could you clarify?"
"Your site doesn't work" "On Chrome/Mac, the video in
'Day 15' won't load. Error:
'Failed to fetch resource'.
Happened at 3pm GMT on June 3."
"Why didn't you cover X?" "I teach teen learners with low
motivation. I'd love a post on
engagement strategies for this
age group."
"You're wrong" "Recent research (cite source)
suggests a different approach
to X. Could you update the
post with this perspective?"
EXAMPLE (daily life): “It does not work” tells nobody anything. “On my phone, the menu does not open when I tap it” can be fixed.
Check 3: Which two details make the “site doesn’t work” example helpful?
Show the answer
Then you wait for the answer. Here is the process.
Segment 4 — What happens after you send it
This is my own process. It is my policy for this site, not a legal rule.
Level 1 — Clarification. Your feedback is read. If I need more detail, I will ask you questions. Level 2 — Acknowledgment. You get an answer within 7 business days. Level 3 — Resolution. Content errors: corrected within 14 days and you are told. Technical issues: diagnosed and fixed, or documented with a workaround. Topic requests: added to the content calendar; expect a post within 30 days or an explanation. UX issues: investigated and fixed in the next site update (typically monthly). Level 4 — Dispute resolution. If you disagree, you can request a second opinion from another colleague, with a response within 10 business days.
Visual 4 — Timeline
What it shows: the four levels in order.
How to draw it: Draw four boxes left to right.
The point it makes obvious: Each level has its own time limit.
L1 Clarify -> L2 Acknowledge (7 business days) -> L3 Resolve (content 14 days; topic 30 days) -> L4 Dispute (second opinion, 10 business days)
EXAMPLE (work): You report a factual error on Monday. You get an acknowledgment within 7 business days and a correction within 14 days.
Check 4: How many days for a content error to be corrected?
Show the answer
Last: privacy, limits and respect.
Segment 5 — Privacy, limits and community standards
Privacy: your feedback is used only to improve the site; your email is never shared with third parties and is used only for a direct reply. GitHub issues are public, so do not put sensitive personal information there. For confidential matters, email is preferred.
What cannot be addressed: immediate one-on-one tutoring (I offer coaching separately); issues unrelated to the site or content (for example general CELTA exam preparation); spam, harassment or abusive messages (deleted without response); demands for refunds (all content is free and always will be).
Community standards: be respectful (disagree with ideas, not people); be specific; be constructive (suggest solutions); be patient, because I manage this site alone and responses are not instant.
Visual 5 — Comparison table
What it shows: public and private channels.
How to draw it: Draw two columns.
The point it makes obvious: Public channels are public; use email for private matters.
PUBLIC PRIVATE GitHub issues Email (anyone reads) (reply only to you)
EXAMPLE (civic life): You want to report a problem that mentions your health. Send an email, not a GitHub issue.
Check 5: Why not put sensitive information in a GitHub issue?
Show the answer
This site exists because people like you care about teaching and learning. Your feedback makes it better. Thank you for taking the time to contribute. 🙏
Sourov DEB
June 2026
Worked example — write a good bug report
The task: A video does not load on the “Day 15” page. Write the email.
| Step | What happens | Why |
|---|---|---|
| 1 | Subject: [BUG] Video does not load on Day 15 | The tag tells me the type at once. |
| 2 | Say where: the page title or address. | I can find the page. |
| 3 | Say what you see: error message “Failed to fetch resource”. | The words help diagnose the cause. |
| 4 | Say your browser and device, and the time: Chrome on Mac, 3pm GMT, 3 June. | I can try to reproduce it. |
| 5 | Add a screenshot. | A picture shows what words cannot. |
Self-explanation prompt: Why did step 4 matter? If I cannot reproduce the problem, I cannot fix it.
Your turn (guided): write the subject line for a suggestion about a post on teen learners. Step 1: choose the tag. (Answer: [SUGGESTION].)
Common mistakes
| Mistake | Why it happens | Fix |
|---|---|---|
| Vague message (“It does not work”) | You are in a hurry or upset. | Give the place, the problem and the device. |
| Sensitive details in a public issue | GitHub feels like a private chat. | Use email for private matters. |
| Expecting tutoring or refunds | The page title says “feedback”. | See “What cannot be addressed”. |
| No subject tag | You forget the format. | Start with [FEEDBACK], [BUG] or [SUGGESTION]. |
Glossary
| Term | Plain definition | Where first used |
|---|---|---|
| feedback | opinion or report about the site | Before you start |
| bug | a technical problem | Segment 1 |
| reproduce | repeat the steps to see the problem | Segment 1 |
| acknowledgment | a reply that says “I received it” | Segment 4 |
| escalation | moving a problem to a higher level | Segment 4 |
| second opinion | a second person gives a view | Segment 4 |
Quick review
- What tag do you use for a bug?
- Which channel suits a private concern?
- Within how many business days do you get an acknowledgment?
- Name one thing the policy cannot address.
- Why add a screenshot?
Show all five answers
2) Email.
3) 7 business days.
4) For example: one-to-one tutoring, spam, or refund demands.
5) It shows the problem and helps reproduce it.
Sources
- All rules, time limits and promises on this page are my own published policy (June 2026), kept as written. They are a promise from me, not a legal guarantee.
- No outside facts were added, so nothing here needed an external source.
Status: rewritten in lecture-notes style on 28 October 2026. Not tested with readers.