Contributing to AcelleMail Development

What this is for#

AcelleMail is a commercial CodeCanyon product — not an open-source project with public pull requests, a Discord, or a "community fork on GitHub". That said, operators do meaningfully shape the product through other channels.

This article is the honest answer to "how do I contribute?" Four real channels that work:

1. High-quality bug reports via CodeCanyon support
2. Well-framed feature requests with business cases
3. Public knowledge-sharing — blog posts, KB-style articles, conference talks
4. Translation contributions via the resources/lang/ directory

Each section explains what works and what the team actually accepts. The legacy version of this article promised a "Community Edition on GitHub" and a Discord — neither of which we can verify exist. We've rewritten honestly.

Channel 1 — High-quality bug reports#

Bug reports are the single most valuable contribution. The team prioritises fixes for bugs that come with clean reproductions.

The format that gets bugs fixed fast#

Send via your CodeCanyon Item page → Comments tab (public) OR Support tab (private; for security-relevant issues). Include:

**AcelleMail version:** 5.x.x (from Admin → About)
**Server:** Ubuntu 24.04 / PHP 8.3 / MySQL 8.0 / Redis 7
**Customer-facing impact:** describe what a real customer experiences

**Steps to reproduce:**
1. Log in as admin
2. Navigate to Lists → New
3. Enter "Test List" + click Save
4. (etc.)

**Expected:** The new list appears in the Lists index.

**Actual:** Error page with message "SQLSTATE[42S02]: Base table not found".

**Error log excerpt** (from /var/www/acellemail/storage/logs/laravel.log):
[2026-05-16 14:32:11] production.ERROR: SQLSTATE[42S02]: Base table or view not found...
{stack trace 5 lines}

**Workaround in use (if any):** Manually run `php artisan migrate --force` makes it work; reproducible on fresh install.

**Frequency:** Every time, on every install I've tried.

Why each piece matters:

• Version + server stack: the team can reproduce in their matching environment
• Customer-facing impact: signals priority (a bug that breaks "create list" affects every operator)
• Steps to reproduce: lets the team verify the fix
• Error log excerpt: points the team at the right code area
• Workaround: signals you're patient (workaround is in place) and the bug is well-understood
• Frequency: "always" is higher priority than "sometimes"

What NOT to send#

• "It's broken, please fix" with no details — ignored
• Screenshots of error pages without the underlying server log — half the data is missing
• Reports from heavily customised installs without first reproducing on a stock install
• Reports of issues already fixed in a newer version (check changelog first)

What to expect in response#

• Acknowledgement within 1-3 business days (CodeCanyon's support SLA)
• Investigation within 1-2 weeks for clear reproductions
• Fix in the next patch for confirmed bugs (so 2-6 weeks until you can deploy it)
• For security bugs: faster — usually patched within days, distributed via emergency patch

Channel 2 — Well-framed feature requests#

The team listens to operators who frame requests as customer problems, not feature wishlists.

The format that gets considered#

**The customer problem:**
My customer ABC Restaurant Group runs daily promotional campaigns to their
50k-subscriber list. They want to throttle sends to a maximum of 1000 emails
per minute to avoid overwhelming their kitchen with simultaneous orders.

Currently the only way to do this is configuring throttle at the sending
server level — but that affects ALL my customers, not just this one. I can't
give each customer their own throttle.

**The ask:**
Per-customer (or per-plan) sending-rate throttle, configurable from the
plan's `options` JSON or a dedicated field.

**Business case:**
This customer pays $400/month. They've asked twice. They're threatening to
move to ActiveCampaign which has this feature. Losing them = $4,800 ARR.

**Workaround we're using:**
Manually pause their campaign and resume it every 60 seconds via a cron
job. Brittle and ugly.

**Would you accept a contributed patch implementing this?** Yes / No.

What gets prioritised#

• Features that unlock new market segments for AcelleMail (cited by multiple operators)
• Compliance-blocking features (GDPR, CASL, accessibility)
• Quality-of-life improvements that ship with high test coverage

What doesn't#

• "It would be cool if..." (no business case)
• Asks that conflict with the platform's direction (e.g. "rewrite the admin in Vue")
• Features needed by exactly one operator with no broader applicability
• Speculative architecture requests

What to expect in response#

• Triage within 2-4 weeks — the team responds with: accept, decline, defer, or "tell me more"
• Accept: added to internal backlog, no specific ETA
• Defer: "interesting but not now" — re-pitch in 6-12 months with fresh data
• Decline: rare; usually with a reason
• For accepted features: typical timeline is 3-12 months from accept to ship

Channel 3 — Public knowledge-sharing#

This is the highest-leverage contribution most operators can make — it doesn't require the dev team's bandwidth at all, and it benefits every operator who comes after you.

Things to share#

• Tutorial-style blog posts on your own site about how you solved problem X with AcelleMail
• Open-source extensions / WordPress plugins that wire AcelleMail to other tools
• Conference talks / podcast appearances at marketing-ops events
• Detailed reviews on tool-comparison sites (G2, TrustRadius, Capterra)
• Translated documentation in your local language
• Case studies of your install (anonymised or attributed — your choice)

Why this matters#

Every potential AcelleMail buyer searches "AcelleMail vs Mailchimp" or "self-hosted email marketing alternatives" before purchasing. The content that ranks shapes the buying decision. Operators sharing real experiences move buyers off Mailchimp toward AcelleMail more effectively than any AcelleMail marketing.

Reciprocity#

The dev team has historically been responsive to operators who do this consistently — feature requests get prioritised, support gets faster, beta access offered. Not transactional, but the team notices.

Channel 4 — Translation contributions#

The most direct form of code contribution that doesn't require dev-team coordination.

AcelleMail's UI strings live in resources/lang/<locale>/refactor/*.php. Each file is a PHP array of key => translation. If your locale's translations are missing or incomplete, you can add them and submit via CodeCanyon support.

# Find your locale's translation status
cd /var/www/acellemail/resources/lang
ls vi/    # Vietnamese
ls fr/    # French
ls es/    # Spanish

# Compare against the canonical en/
diff <(ls en/) <(ls vi/)   # Files missing from Vietnamese

For each missing file:

1. Copy from en/: cp en/refactor/admin_plans.php vi/refactor/admin_plans.php
2. Translate each string value (keep the keys identical)
3. Test by setting your install's language to vi and walking through the affected screens
4. Submit the translated files via CodeCanyon support with "I'd like to contribute Vietnamese translations for files X, Y, Z"

Translations are usually accepted within 1-2 weeks and shipped in the next patch.

Note: the i18n architecture is evolving — see AcelleMail i18n project if you're contributing structurally rather than just translating strings.

What you CANNOT do#

To set realistic expectations:

• Submit a pull request to a public repo — AcelleMail's source isn't on a public GitHub
• Become a maintainer in the open-source sense
• Fork and redistribute the code (the licence prohibits this)
• Talk to other contributors in a public chat — there's no official Discord/Slack as of 2026
• See the internal issue tracker — it's not public

If "public open-source collaboration" is core to how you want to engage with a product, AcelleMail isn't currently set up for that. Channels 1-4 are the actual surface area.

Building a long-term relationship with the team#

Operators who become "known to the team" over months/years get:

• Faster bug fixes
• Priority on feature requests
• Beta access to upcoming features
• Sometimes informal roadmap conversations

This isn't transactional or hidden — it's just normal human relationship-building, applied to a small dev team. The pattern that works:

• File high-quality issues consistently (not many low-quality ones)
• Respond promptly when the team asks for clarification
• Share publicly (Channel 3) — being visible in the AcelleMail ecosystem makes the team notice you
• Be patient about timelines — 6-12 months is normal for feature delivery
• Pay it forward by helping other operators in public channels

FAQ#

Is there a public roadmap I can vote on? No formal voting system. See AcelleMail 2026 Roadmap for the roadmap-discovery channels.

Can I sponsor a feature? Talk to support — for substantial bounties on specific features, the team has historically been open to sponsored development. Don't expect <$5k bounties to move the needle.

Can I build and sell an AcelleMail plugin? Yes — extensions you build under the plugin architecture (or as WP / Zapier integrations) are yours to sell. They aren't part of AcelleMail's source.

What if I find a security vulnerability? Report PRIVATELY via CodeCanyon Support (not in public comments). Include reproduction steps + your suggested severity. The team typically responds within 24-48 hours for security reports.

Is there a bug bounty? Not formally advertised. Significant security findings have historically been rewarded; coordinate via private support.

Can I publish an AcelleMail "Awesome List" on GitHub? Yes — operators have created repos listing extensions, integrations, related tools. Not officially endorsed but welcomed.

Where do I find other AcelleMail operators to talk to? Beyond direct CodeCanyon comments + relationships you build at conferences, no official central channel as of 2026. Suggest creating one if you have the bandwidth — it would be a meaningful contribution.

Related articles#

• What's New in AcelleMail — release cadence
• AcelleMail 2026 Roadmap — direction the platform is heading
• Community Spotlight: Business Case Studies — operator stories worth contributing to
• Extending AcelleMail Source Code — how to build extensions you may want to share
• Getting Started with the AcelleMail REST API — for integration extensions
• Setting Up AcelleMail as a SaaS Platform — the SaaS-operator community is the most active contributor pool
• Post-Install Hardening Checklist — security knowledge to share back