A GitHub awesome list looks like a straightforward place to share a useful product. Find a relevant section, add a line and open a pull request. The real work comes before that edit: establishing whether the list wants your kind of contribution and whether the proposed entry helps its readers.
In October 2026 we reviewed 48 curated lists covering startup resources, launch sites, SaaS tools and web tools. An early screening snapshot recorded 36 requests and 12 lists left alone. The later October 29 tracking export contains 44 pull request rows. These are different checkpoints, not one arithmetic split. RadarMakers is a free launch directory for indie makers, so relevance depended on the purpose of each list.
The October 29 export records 39 rows as open and 5 as closed. It does not say which closed requests merged, and an open request remains unresolved. The ledger records submission dates from October 20 to 28. It gives us an activity record, not a formula for getting accepted.
Which lists are candidates for a startup?
The record includes pull requests to Founders Kit, SaaS4Devs and Awesome Free SaaS. It also includes lists devoted to startup launches, SaaS directories, visibility and developer tools. These are examples to investigate when the resource you want to contribute matches that audience.
The wording matters: the ledger records request activity, but the export does not show which of these named candidates accepted a request. It also does not establish that every startup is eligible to submit. Verify a merge on the individual pull request page before naming an accepted repository.
A launch directory and a browser utility can belong in different places. The directory may help readers find somewhere to announce a product. A utility may help them complete a development or design task. Decide which resource is useful to the list before deciding which page of your product to promote.
A good candidate has a relevant section, rules your contribution satisfies and evidence that outside contributions receive attention. The title of the repository alone cannot establish those things.
The skipped lists explain the boundaries
The largest list in the record had 140,257 stars. We skipped it because its contribution rules rejected pull requests written with AI assistance. Popularity did not override that requirement. If your contribution process conflicts with a rule, choose another destination rather than disguising how the submission was prepared.
Another list prohibited additions to categories already containing ten or more entries. Others excluded promotional submissions for newly launched products or closed requests that added the submitter's own product. These are different restrictions, and each can rule out an otherwise relevant entry.
One list's rules allowed standalone developer products while excluding features of a larger product. Another limited submissions to open source or source available products. A design resources list required submitted sites to have been publicly available for at least three months.
These examples make eligibility a concrete check. Ask whether the product is old enough, whether its source qualifies, whether self promotion is permitted and whether the category has room. A useful tool can still be unsuitable for a particular collection.
Activity needs more than a recent push
Our record includes lists we skipped because of their pull request history. In one case, no pull request had been merged since August 2025. In another, an external request had remained open since May 2026 when we checked.
Those observations affected where we spent effort. They do not prove that a maintainer has abandoned a repository or will never accept another contribution. They show uncertainty about the review path at the time of inspection.
The page records stars and last push dates from GitHub on October 28. A push date tells you when repository activity occurred. Looking at merged contributions from other people answers a more specific question: has this list recently accepted outside edits?
Check both before submitting. A polished README and a large star count can coexist with a slow contribution queue. Stars indicate that people have found a list; they do not measure current readers, referral visits or customers.
Prepare an edit that is easy to assess
The source page recommends reading the contribution rules, finding a matching section, following the format of existing lines and checking recent external merges. The workflow below turns that advice into a practical editing process. It is guidance, not a result measured across our requests.
Read the rules before drafting the entry. Look for requirements about eligibility, descriptions, placement and disclosure. If the rules prohibit your submission, stop there. Rewording an ineligible product does not solve the underlying mismatch.
Next, read the neighboring entries. Match their level of detail and presentation. If the section uses concise descriptions, explain the concrete task your resource handles in similarly concise language. Avoid unsupported claims about being the best or fastest option.
For a directory, describe what readers can find there. For a tool, describe what it does. A maintainer should be able to assess relevance from the proposed line without having to translate marketing copy into a product function.
For example, the descriptive part of an entry could read:
RadarMakers: A free launch directory for indie makers.
That is an illustrative draft, not a quotation from a merged request. Adapt the link syntax and punctuation to the destination's existing entries. In the request description, explain that the addition belongs in its launch resources section, if that section exists and permits it.
Keep the change focused on the intended addition. Unrelated reformatting creates more material to review and can obscure the contribution. Before opening the request, inspect the diff and verify that the destination works.
Explain fit in the pull request
The request description should explain why the entry belongs in the chosen section. Name the relevant function and show how the submission follows the repository's rules. Disclose your connection to the product when required, and describe it honestly whenever it matters to evaluating the contribution.
Distinguish what your product does from what you hope the listing will achieve. A maintainer curates a resource for readers. Your traffic goals do not establish the usefulness of the addition.
After submitting, keep the outcome accurate. Open means waiting for a decision. Merged means the change was accepted into the repository. Neither label tells you how many readers clicked through or whether anyone became a customer.
If feedback arrives, address the specific concern and recheck the rules before revising. A requested correction can improve a suitable entry. A policy excluding the product is a reason to accept the decision and move on.
What this record can teach
The most useful lesson from the screening and tracking records is to check fit before submitting. Rules excluded some destinations, product scope excluded others, and review history helped us decide where an attempt was worth the effort.
The October 29 tracking export contains 44 rows: 39 open and 5 closed. It does not establish which closed requests merged, a typical waiting time, or a traffic return. Prepare a contribution that fits, record the outcome accurately, and let the maintainer decide.
Read the tracking export as a dated ledger
The local tracking export is more specific than a general count of outreach. Its first line records 44 tracked pull request rows. Each following row gives a state, a close date when present, a submission date, a repository name, and a star count captured for that list. The export does not include review comments, merged commit IDs, referral visits, or the reason a request closed. It is an activity ledger, not a conversion report.
On October 29, the ledger contains 39 open rows and 5 closed rows. Closed is not a synonym for merged. A pull request can be merged, rejected, closed without review, or replaced by another request. Without a merge-state field or a link to an authoritative pull request record, this file supports only the open and closed distinction. Do not count closed rows as wins.
The dates are also uneven. The record groups submissions on October 20, 24, 26, 27, and 28. The chart shows the volume recorded for those dates. It does not imply that the same number of maintainers reviewed the work on each day, or that submission volume produced acceptance. A quiet day can reflect a deliberate pause to inspect rules rather than a lack of candidate lists.
Separate the review set from the request set
The original screening note describes 48 lists reviewed, 36 requests opened, and 12 lists left alone at that review point. The later export contains 44 tracked request rows. These totals describe different snapshots and should not be combined into a single partition. Some requests were added after the earlier count, while the export is organized around tracked requests rather than every list that was screened.
This is a small recordkeeping detail with a large effect on the story. If a report says 48 lists were reviewed and 44 requests were tracked, it should not imply that exactly four lists were skipped. The unit called a list review is not the same as a pull request row. A repository can appear in a screening pass without a request, and the later request ledger can grow as more candidates are evaluated.
For your own outreach, store those units separately. One table can represent candidate destinations and the decision to submit or skip. A second can represent actual requests and their status changes. Record the decision date, the reason for a skip, the request URL, the state, and the last checked time. This makes it possible to distinguish screening effort from submission volume without retroactively changing totals.
The first title in this article used an earlier pull request count. The current article follows the October 29 export for the request charts and states that date wherever it reports status. The older summary remains useful as a dated checkpoint, but it should not be mistaken for the newest ledger.
Submission timing is not a response-time benchmark
The chart by date describes when tracked rows were submitted. The available table does not provide a response timestamp for open requests and cannot establish how long maintainers took to review them. A later close date appears for some rows, but that field alone does not identify the decision or the time spent waiting for an answer.
A useful outreach analysis separates submission time from review time. For each request, retain the timestamp when it was opened, the first human response, every requested change, the merge or close event, and the last observation. If the request remains open, describe it as open at the observation date. Do not assign a projected acceptance date based on another repository's behavior.
When calculating elapsed time, state the start and end events. Time from opening to first response is not the same as time to merge. A request with a quick comment and a long implementation gap has a different path from a request that receives no response. These distinctions are useful for planning follow ups, but they do not predict an individual maintainer's next action.
The record also shows why a daily bar chart should not become a performance ranking. A high count on October 28 may reflect a batching session, not a successful process. If you repeat the analysis later, compare comparable time ranges and include requests that are still open. Excluding unresolved rows makes the apparent outcome rate look better than the full queue.
Stars are context, not expected reach
The export includes a star count for each repository. The highest listed counts include 513 for serpapi/awesome-seo-tools, 471 for best-of-ai/ai-directories, 274 for iAmCorey/awesome-indie-hacker-tools, and 270 for teles/awesome-seo. Those figures help describe the repositories in the saved snapshot. They are not a count of people who read an entry, a count of visitors sent to a linked product, or a measure of the chance that a pull request will merge.
A popular list can be a poor candidate if it forbids promotional additions or has an inactive review path. A smaller repository can be a better fit if its audience and section are directly relevant. Star totals are cumulative user actions and can lag changes in a repository's focus. They also do not show how frequently a list appears in search results or whether readers follow its links.
Use stars as one field among several, not a ranking rule. Read the README, inspect the section where an item would go, and check whether the rules allow the proposed resource. Look at recent commits and external contributions. If there are many stars but no visible maintenance, treat review timing as uncertain rather than assuming the list will deliver attention.
If you later measure referral traffic, keep the referrer and landing path connected to the source list. A visit that arrives from a repository page is evidence of a click, not evidence of a sale. Record the measurement window and filter bots or internal checks before drawing conclusions about audience quality.
Recheck repository rules immediately before editing
A rule can change after a previous review. Before opening a branch or preparing a pull request, read the current contribution guide and the section file. Check whether the repository accepts directories, products, commercial tools, new launches, or self submissions. Look for a required license, age threshold, source availability condition, description length, or proof that the site works.
If the repository requires a contribution made without AI, do not use an AI-generated line there. If it allows a tool but rejects a directory, do not submit a directory because another part of the project seems related. When the wording is ambiguous, ask the maintainer through the channel the repository provides or select a clearer destination. Do not conceal the relationship between the submitter and the resource.
Rules may be split across a contribution guide, a README section, issue templates, and recent decisions. Read all of them. A section heading can appear relevant while the policy below it excludes the exact product type. A repository can also temporarily freeze new entries. Preserve a short note of the rule and the date you checked it so another person can understand why a destination was skipped.
The cost of this check is usually lower than preparing a polished contribution that must be withdrawn. More importantly, it protects the list from irrelevant additions. A resource earns a place because it serves the collection's readers, not because the submitter has a launch campaign underway.
Keep the patch small and reversible
A contribution should change only the line or section needed for the resource. Avoid reformatting nearby entries, changing unrelated punctuation, or moving a list around to make the new item prominent. A focused diff helps a maintainer review relevance and reduces the risk of accidentally deleting another person's work.
Use the repository's existing format. Match its capitalization, link style, description length, and ordering. Run the checks described in the repository. If there is no automated check, inspect the rendered Markdown, verify that the link resolves, and confirm that the line does not contain unsupported claims. A grammatically polished entry can still be wrong for the destination.
Before submission, read the diff in plain text and on the rendered page. Check that the resource name is accurate, the URL is canonical, and the description says what a visitor can actually do. If the list permits a short rationale, explain the section fit in one sentence. Keep SEO phrases out when they make the entry less useful to a human reader.
After opening a request, do not push unrelated changes into it. Respond to requested edits directly and keep a local record of each revision. If the request is closed, inspect the reason before trying again. Reopening the same rejected request without fixing the issue creates work for maintainers and teaches little about the underlying rules.
Report outcomes without overstating them
An open request is pending. A closed request is no longer open, but the ledger does not reveal why it closed. A merge is a verifiable code event and should be counted only when the pull request page or merge commit confirms it. A referral is a separate analytics event. A qualified visitor, signup, or customer is another step beyond a click.
Use language that names the evidence. For example, the saved export supports the sentence: "The October 29 ledger contains 44 rows, 39 marked open and 5 marked closed." It does not support: "44 lists accepted our resource" or "the submissions generated visitors." The first sentence is narrower but durable. The unsupported versions turn an activity count into an outcome claim.
If a report needs an acceptance rate, define the denominator and the decision states. Decide whether a merged request counts as accepted and how to treat closed without merge, withdrawn, duplicate, or still open. Freeze the observation date, then calculate from that snapshot. Never drop pending requests simply because they are inconvenient to classify.
This discipline matters when comparing one outreach channel with another. A repository list, a newsletter, and a directory form do not share the same review process. Track their submitted, live, link attribute, and referral outcomes separately. Only then can a later analysis explain which kind of work produced useful discoveries.
Sources and record limits
The article's counts come from the local tracking file prs-2026-10-29.tsv. That file has a header value of 44 followed by 44 request rows. Its state field contains 39 open and 5 closed values. It records dates and star counts but not merge outcomes or referral traffic. The earlier 48-list screen and its 36-request snapshot are preserved as a separate dated note.
The recommendations in this article are editorial guidance based on those fields and the recorded contribution rules. They are not a measured experiment showing that a particular sentence or number of stars causes a merge. The safest use of the record is to improve screening, keep status language honest, and make future logs more useful.
For the recorded screening and submission notes, see our GitHub awesome lists for startups.
Top comments (0)