Example report. This repository does not exist. The data is made up to show what a report looks like.
example-org/
A durable job queue for Node.js services, backed by Postgres.
8.4K stars512 forksTypeScriptMIT
9 / 10
Should you contribute here?
Most signals point to a project that is open to new contributors.
- 9yes
- 1no
Not a score. Each one is a yes or no you can check below.
- ✓Does it have an open source license?MIT license detected.
- ✓When was the latest commit?Today, on the default branch.
- ✓How often do people commit?Commits landed in 13 of the last 13 weeks.
- ✓How many contributors does the project have?6 people authored commits in the last 90 days.
- ✓Are issues getting closed?13 issues closed and 20 opened in the last 30 days.
- ✓How recently were any pull requests merged?The last merge was 2 days ago.
- ✓Do outside pull requests get merged?29 community pull requests merged in the last 90 days, out of 41 closed; 7 more landed as commits.
- ✓Do maintainers respond quickly?66 of 69 community threads were answered or closed; a first reply typically takes 26 hours.
- ✕Is there a contributing guide?No contributing guide in the standard locations.
- ✓Are there issues marked for newcomers?5 unassigned issues labelled good first issue or help wanted.
How this is worked out
- Does it have an open source license? Yes when: GitHub detects a license, and it is not a known source-available one (BUSL, Elastic, SSPL, FSL, PolyForm, Commons Clause).
- When was the latest commit? Yes when: Latest commit within the last 30 days.
- How often do people commit? Yes when: Commits in at least 7 of the last 13 weeks, or at least 100 commits in the last 30 days.
- How many contributors does the project have? Yes when: More than one person authored commits in the last 90 days.
- Are issues getting closed? Yes when: At least one issue closed in the last 30 days.
- How recently were any pull requests merged? Yes when: A pull request merged within the last 30 days.
- Do outside pull requests get merged? Yes when: At least 3 pull requests from outside the team were merged. A no needs at least 30 days of history with 3 or more closed. Work that landed as a commit crediting the contributor counts as merged.
- Do maintainers respond quickly? Yes when: At least half of community threads older than two days were answered or closed, with a median first reply within 48 hours.
- Is there a contributing guide? Yes when: GitHub detects a CONTRIBUTING file.
- Are there issues marked for newcomers? Yes when: At least one unassigned open issue labelled good first issue or help wanted.
- The questions come from GitHub’s Open Source Guide. Friendliness cannot be measured, so read a few recent threads yourself.
Where do I start?
2 of the 4 starter issues we checked look free to take.
- good first issuewritten by a maintainerDocument retry backoff optionsLooks free: no open pull request, nobody has asked for itOpened 6 days ago · 3 comments · nobody assigned
- good first issueAdd example for scheduled jobsTaken: pull request #1812 is open for itOpened 15 days ago · 1 comment · nobody assigned
- help wantedSupport custom logger in worker optionssam-whitlock asked to take it 26 days ago. Worth asking if it is still theirsOpened 31 days ago · 7 comments · nobody assigned
- help wantedwritten by a maintainerFlaky test: concurrency limit under loadLooks free: no open pull request, nobody has asked for itOpened 48 days ago · 5 comments · nobody assigned
1 more unassigned starter issue is open. We only check the first four in detail.
What the project gives you to work from
- READMEfound
- Contributing guidenot found
- Code of conductfound
- Licensefound
- Issue templatesfound
- Pull request templatenot found
Pull requests normally target the default branch, main. Check the contributing guide in case this project uses another.
How this is worked out
- Starter issues are open issues labelled “good first issue” or “help wanted” with nobody assigned. Projects with their own labels show none.
- For the first four we read the issue’s history. “Looks free” means no open pull request refers to it and nobody outside the team has written that they want to take it. We match common phrases, so an unusual wording can be missed.
- A contributor licence agreement is inferred from a known CLA bot commenting on recent pull requests. Projects that enforce one some other way are not detected.
- Files are detected by GitHub in the standard locations only.
What happens to my pull request?
36 pull requests from outside the team got merged in the last 90 days.
Where outside pull requests ended up
- Merged2963%
- Landed as a commit715%
- Closed without merging511%
- Still open511%
29 of 54 merged pull requests came from outside the team.
The proof: recently merged from outside the team
How long people waited for a first reply
- Within a day2637%
- Within a week3346%
- Closed, no reply seen811%
- Still waiting46%
2.5days
typical time to merge, from outside
The team's own: 3 days
26hours
typical wait for a first reply
6weeks
of pull requests in the queue
23 open, about 4 merged a week
How this is worked out
- “Outside the team” means the author is not an owner, organisation member or collaborator, and not a bot. Members who keep their membership private count as outside.
- “Landed as a commit” is a pull request that was closed rather than merged, where a later commit mentions it or credits its author. Some projects apply outside work this way, and it would otherwise look like a rejection.
- Closed without merging includes withdrawn, duplicate and low-quality submissions. It is not a measure of how fairly reviews are done.
- A reply is the first comment from another person, or a merge. Bot comments are ignored. Approving a pull request without commenting is not visible to us, so those show as “closed, no reply seen”.
- The queue is open pull requests divided by pull requests merged per week (bots excluded). It is a rough guide to how crowded review is, not a waiting time.
- Figures cover the longest recent period we could read completely: 90 days when possible, less on very busy repositories. Typical means the median.
Who will I work with?
These maintainers do most of the replying to newcomers.
Maintainers who reply
- jonas-lindqvist17 threads
- priya-raman17 threads
- mira-okafor16 threads
Who wrote the code, last 90 days
6people
- mira-okafor53%
- jonas-lindqvist15%
- priya-raman15%
- t-nakamura8%
- 2 other people9%
How this is worked out
- Maintainers are owners, organisation members and collaborators, ranked by how many issues and pull requests from outside the team they commented on.
- The chart counts commits on the default branch, bots excluded. A squash merge credits whoever merged, so reviewers can look larger than authors.
- Work that is concentrated in one or two people is common and not a problem by itself; it tells you whose attention you will need.
When will someone see my question?
When maintainers are usually around.
Maintainers are most active on Mondays, around 08:00–11:00 your time (UTC).
Mon
Tue
Wed
Thu
Fri
Sat
Sun
00:0006:0012:0018:00
Based on 50 comments by team members. Each square is one hour.
Is it my kind of project?
Mostly TypeScript.
- TypeScript88.2% of the code
- JavaScript6.6% of the code
- PLpgSQL4.2% of the code
What recent issues and pull requests are about
- bug43
- enhancement43
- documentation22
- dependencies21
- postgres21
- worker21
How this is worked out
- Languages are shares of code by bytes, as GitHub detects them. Generated or vendored files can skew the picture.
- Labels are counted on issues and pull requests opened in the last 90 days, and depend on how the project labels its work.
Is the project alive?
Commits landed in 13 of the last 13 weeks.
- Last commit
- today
- Last release
- 14 days ago
- v2.14.0
- Last merged pull request
- 2 days ago
- Last closed issue
- today
Commits per week
18
9
13
11
10
17
9
19
16
17
15
5
Week of Jul 7Week of Sep 22
Issues, last 30 days
Opened20
Closed13
Pull requests, last 30 days
Opened33
Merged24
A new release roughly every 23 days.
How this is worked out
- Commits are counted on the default branch (main).
- Merges and closed issues are only looked for in the last 90 days, so “never” means none in that period.
- Release rhythm is the median gap between the most recent releases published on GitHub. Projects that only use git tags show none.
- Activity is not quality: a quiet project can simply be finished.