Just opening a thread to let you know that I'm currently working on our review process.

My main goal is to be able to use filter is:open is:pr review-requested:@me sort:created-asc -is:draft -author:@me -status:failure as a definitive work list

Questions:

• Who are the members of the core team?
• What is everybody specialized in and focusing on?
• What's the current role (as in permissions) in the projects?

We often have people post comments in issues that have been closed for years. This bypasses the issue template, so we don't receive a lot of the important information, and the issue is usually not related due to the codebase having changed massively since then.

Should we auto-lock closed issues if they don't receive any activity for a few months? Maybe 3 months? 6 months?

GitHub action we can use: https://github.com/marketplace/actions/lock-threads

I have just merged sequelize/sequelize#13569.

What are the next steps?

I usually don't mind if PR reviews are taking time and that a review might drag on for a week or two.
However, I think we should be all hands on deck if people used OpenCollective to get something in on higher priority.

Concrete examples were the PRs

• sequelize/sequelize#14804
• sequelize/sequelize#14852
• sequelize/sequelize#14882

At time of writing, we are raising around 650 USD per month.
This is already amazing, but considering the scope of the ORM, the ideal situation would be to have one of us work on the ORM as close to full time as possible. This would require a budget of 5000 USD to 15,000 USD per month.

Current State

We already use the following platforms to raise funds:

• OpenCollective
• thanks.dev
• GitHub Sponsors

We also receive funds from ads on the website

Recently, we've also had workday offer to sponsor the development of specific features

What can be improved

• We should incentivize companies to donate
  • We could add the list of sponsors on our home page, with a call to action to OpenCollective.
  • We should rework our Open Collective page to be more professional / cleaner than what we currently have. We should also remove the bugfix/feature tiers as they are highly undervalued compared to the cost of actually implementing a feature.
• Companies sponsoring specific features is amazing. We should add calls to action to contact us for estimates for feature requests.
• We could consider partnerships with companies that do work closely related to ours. For instance:
  • Maybe we could propose a partnership with https://neon.tech to display ads for them in our new "How to use Sequelize with Postgres" guide
  • There are many companies offering solutions for migrations. We could see if one of them wants to do a partnership and display ads for them on our pages about migrations.
  • Some companies extend the features of databases, such as https://timescale.com. We could contact them about adding support for them in our ORM (and possibly ads) in exchange for sponsoring
  • My research focuses on postgres because that's my database of choice but if you know of other potential partners for other databases, that's worth looking into
• We can reach out to companies that we know use Sequelize, and ask them if they are willing to sponsor the ORM

I've usually been opposed to prettier because it does not allow me to decide on the code style as much as I'd like, but I have to admit that the output generated by prettier has improved over the years.

Considering that our eslint preset can be very slow on some files (i even upgraded my setup with this as one of the reasons), and that prettier is very fast. I think we could consider replacing all stylistic eslint rules that prettier handles with prettier, and keeping eslint for bug detection & elements that prettier does not handle yet.

Oh, and prettier-plugin-organize-imports automatically removes unused imports on format

Questions:

• How many donations did we have in Q4 2021?
• How does the donation platform look like and work?
• How do we share the donations among the core contributors?

I'm been trying out codespaces to see what the experience is like and now I'm wondering if it would be worth it to setup a "Open in codespaces" button in our repos (at least in the main one, website, and sscce)

If we can configure it to be usable out of the box, i.e. that the dev wouldn't need to do any further configuration work, it could reduce the barrier for contributing to the project

I have created this issue here, as I didn't find much information about how to join the core team.

Would love to know more about the current requirements (in the team) and what exactly it is looking for.

If this issue is irrelevant, please feel free to close this off

Mark: Rik reviewed the PR and gave feedback. Remaining questions

• CI/CD strategy: Run smoke tests every so often on main only. Let's do it afterwards.

Running all integration tests takes roughly 20 hours. Majority of tests are working fine. One final commit will come in and then it should be ready.

Mark: Work on the smoke test in a future PR and notify the slack channel in case of failure (maybe changelog).
Please disable the integration tests for db2 for i in the PR.

Did we figure out why db2 fails randomly: Once the PR for db2 for i is completed, Mark will look into it.

Update March 23rd:
PR has landed, release under some v7 alpha version
Mark wanted to work on the integration. No update yet.

Update April 21st:
To be confirmed: Kevin Adler is taking over the work.
@sascha configure the Github Action. Double check with Mark + Kevin what is happening with the flaky db2 tests.

ephys: 44% (total: 141, pr: 94, issues: 0, comments: 47)
WikiRik: 24% (total: 78, pr: 42, issues: 0, comments: 36)
sdepold: 22% (total: 71, pr: 46, issues: 3, comments: 22)
bl0cknumber: 5% (total: 18, pr: 16, issues: 0, comments: 2)
jesse23: 1% (total: 4, pr: 4, issues: 0, comments: 0)
AllAwesome497: 0% (total: 3, pr: 0, issues: 0, comments: 3)
Bishwodahal: 0% (total: 2, pr: 2, issues: 0, comments: 0)
janmeier: 0% (total: 1, pr: 0, issues: 0, comments: 1)

There is the idea of offering different support levels to users of Sequelize so that they could get premium access to prioritized feature and bug support. This would be offered through OpenCollective plans.

Furthermore, to give anyone an incentive to contribute to bug fixed or feature asks, we could utilise available bounty program platforms. We tried out IssueHunt for that but it turned out it's not save to be used. We could also look into BountySource: https://app.bountysource.com/teams/sequelize/issues?tracker_ids=266075

Open question: Can everybody request the bounty upon fixing something?

Sascha: Create OC plans.
Any core member: File PR against the website. Here is a proposal https://gist.github.com/ephys/d056f30d33834694c515cd664f201d8c

Hi Everyone,

Today I received an email stating Issuehunt is being added to Sequelize project. I know I have left the project but this was important so I am posting this here. I don't think Sequelize should add Issuehunt.

Why?

• They don't have an automated way to withdraw your funds. Withdrawal emails (or any other emails) are usually ignored.
• You need to earn at-least $100 USD to withdraw.
• As a project owner, you can't get funds stuck in stale issues. If there is a bounty on an issue, it can't be utilized for something else.

Idea of bounties is great but these platforms are shady at best. I don't want contributors money get stuck in some third party platform.

Thanks!

Questions

• Which problems do we see right now with PRs?
• Do we want to enforce update with master in PRs in the future?

I think I'll check quarterly who is still actively participating and propose an update in terms of access to the internal slack channel as well as permissions on the repos.

Maybe search for new core members could also be added to the PR template.

Feature Description

Is your feature request related to a problem? Please describe.

I've personally never liked the ergonomics of having to use sequelize operators as keys for an object.
The following code

const where = { id: { [Op.notIn]: blockList } };

feels easier to read when written like this:

const where = { id: Op.notIn(blockList) };

Describe the solution you'd like

We could make it possible to use Op.* as both object keys and functions using toPrimitive. That would make both snippets of code above valid.

Proof of concept:

const symbolNotIn = Symbol('notIn');

function notIn(val) {
  return { [symbolNotIn]: val };
}

notIn[Symbol.toPrimitive] = () => {
  return symbolNotIn;
}

console.log(notIn([1, 2]));        // output: { [Symbol(notIn)]: [1, 2] }
console.log({ [notIn]: [1, 2] });  // output: { [Symbol(notIn)]: [1, 2] }

export const Op = {
  // ...
  notIn,
  // ...
};

Why should this be in Sequelize

I believe this would make the usage of operators easier to read and understand.

Describe alternatives/workarounds you've considered

If using Symbol.toPrimitive feels too much like magic, those functions could be provided somewhere else. Sequelize.and, Sequelize.or, etc already exist.

Additional context

N/A

Feature Request Checklist

Is this feature dialect-specific?

• No. This issue is relevant to Sequelize as a whole.
• Yes. This issue only applies to the following dialect(s): XXX, YYY, ZZZ

Would you be willing to implement this feature by submitting a Pull Request?

• Yes, I have the time and I know how to start.
• Yes, I have the time but I don't know how to start, I would need guidance.
• No, I don't have the time, although I believe I could do it if I had the time...
• No, I don't have the time and I wouldn't even know how to start.

There was a plan to add this to v6 (sequelize/sequelize#11400), but there was never a PR raised for it. Maybe it's good to discuss if we can add this to v7, seeing that sqlite3 is not able to push new builds currently; TryGhost/node-sqlite3#1508 (and the advantages that better-sqlite3 brings over sqlite3 of course)

I'm testing the GitHub issue forms, which does not currently allow adding maintainer-defined markdown to the created page.

So instead I'm considering having a bot post React with 👍 on the top post to indicate your interest. Comments such as '+1' will be automatically hidden and having another bot automatically collapse what refined github considers to be "low quality comments": https://github.com/refined-github/refined-github/blob/main/source/helpers/is-low-quality-comment.ts#L1

Questions:

• Which requirements do we have towards the code, CI/CD, long-term support?
• Should we keep the code in the core repo or somehow split the dialects / SQL queries from the core repo?

I will update this issue later with more, but there's several things we could do upon releasing v7. Mainly we need to promote the new features and the new scoped package name.

We can do that through;

• Submitting us for the monthly GitHub Release Radar; https://github.com/github/release-radar
• Contacting StackShare and other websites to update their comparison between us and other JS ORMs

What we should also do;

• Contact the maintainers for the projects mentioned in the docs (Resources / Awesome Sequelize) + README to make sure their projects can work with v7 around the release date
• Update contributing guide now with new supported versions, docs in the website repo etc
• Updating outdated information spread around the internet, like comparison with other ORMs. E.g. Prisma

Feel free to comment with more

After releasing v7 we'll still be working on future migration of methods to TypeScript which will likely also include more usages of rejectInvalidOptions to not silently ignore options anymore. Do we see that as a breaking change or a change that requires a minor release? Because it will likely break some projects, but the further functionality is not changed if they remove the invalid option (unless they're using different dialects in different environments).

Personally I see it as a breaking change but I think we can make it opt-in with a global option for v7 so don't have to postpone releasing those on a stable version.

What are your thoughts?

cc @sdepold @ephys @lohart13

Hi all :)

I'm opening this to talk about what we want our SemVer MAJOR release policy to be.
Right now, for v7, we've opted for the approach of "implement as many breaking changes then release v7"

I'd like to discuss an alternative policy: Releasing SemVer MAJOR releases on a fixed schedule.

The main reason behind it is that a lot of our dependencies already release their Major versions following a fixed schedule ; and, more importantly, EOL their old versions at fixed dates.

If we wait until we have enough breaking changes for v7 to release, we'll be stuck supporting versions of Node, Postgres, etc that have been EOL for a long time (because of v6).

What I'd like to do instead is this:

• Every year in May-June, we release a new SemVer MAJOR version of Sequelize. I've picked these months because Node typically EOL in April.
• New SemVer MAJOR releases only support TypeScript versions that were released in the past 365 days (we don't drop TypeScript versions between SemVer MAJOR releases).
• New SemVer MAJOR releases only support maintained versions of connectors, databases, and Node (at time of release).
• We drop support for a Sequelize version 6 months after its replacement was released. As such, each version would be maintained for a year and a half total.

This also make it easy to be explicit about which version supports which dependency:

Imagine we're in mid-june 2022, our version table would look a bit like this (with most dialects omitted):

Table built based on:

• https://github.com/microsoft/TypeScript/wiki/Roadmap
• https://nodejs.org/en/about/releases/
• https://www.postgresql.org/support/versioning/

This thread documents some general guidance on how to effectively collaborate as a team.