✋Looking for maintainers

[mweststrate]

I am looking for maintainers of this repository. That probably won't be too much of a burden (no big features in the planning), as it is mostly reviewing an occasional PR and releasing it. But there are some funds available to compensate if it is gonna cost you too much time.

MobX development is NOT terminated

How to start contributing

[ItamarShDev]

I will be happy to help
not sure I am qualified though

[mweststrate]

@ItamarShDev no worries, I can try to guide you through it the first few times! And I think @capaj and @urugator will be willing to chime in with their knowledge were needed as well. It is mostly making sure things don't linger around for too long!

For my own sanity, I am going to unwatch the repositories, but if my input is needed, just nudge!

[ItamarShDev]

Cool!
Well if any of the members will agree, I will be happy to maintain and help as much as i can!

Also, I hope i could get some guidelines and guidance, so i could do the best job i can :)

[mweststrate]

I'll compile a list in the coming days! Ping me if I didn't :)

…

On Tue, Jun 4, 2019 at 11:10 AM itamar sharify ***@***.***> wrote: Cool! Well if any of the members will agree, I will be happy to maintain and help as much as i can! Also, I hope i could get some guidelines and guidance, so i could do the best job i can :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/mobxjs/mobx/issues/1983?email_source=notifications&email_token=AAN4NBG35P7SZEDH4XJAI6DPYYWP3A5CNFSM4HSZ5RL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW3545Y#issuecomment-498589303>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN4NBFYVKL44GGLL4JMNELPYYWP3ANCNFSM4HSZ5RLQ> .

[spion]

cc @benjamingr

[benjamingr]

Hey, I don't mind picking up more of the burden here.

We can also adopt this at the open source initiative in jsil.

Also - consider joining the OpenJS foundation

Feel free to ping me about any or all of this in private channels :)

[aretecode]

feel free tag or request me for any reviews 👍

[StephenHaney]

Time is always tight, but I’d love to support however possible! Big fan of the project.

[mweststrate]

Awesome guys, thanks a lot! I'll try to compile a list of things I generally do in a couple of days!

…

On Wed, Jun 5, 2019 at 6:30 AM Stephen Haney ***@***.***> wrote: Time is always tight, but I’d love to support however possible! Big fan of the project. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/mobxjs/mobx/issues/1983?email_source=notifications&email_token=AAN4NBELQOVJVRPEVMFOMU3PY46PRA5CNFSM4HSZ5RL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW6SETQ#issuecomment-498934350>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN4NBBABC3HUOARBIP46BLPY46PRANCNFSM4HSZ5RLQ> .

[danielkcz]

@mweststrate Are you going to give access for NPM publish to everyone as well? I am not saying people are generally trying to do any harm, but more people with access means potential security hole. I think it would be wise to require 2FA enabled for anyone who will be pushing to NPM.

[rdewolff]

Would be happy to help as well, with some guidance.

[mweststrate]

Thanks guys for the responses! Heartwarming! Will send invites in an iffy.

@FredyC I think we can keep NPM access currently limited to you, xavier, itamar and those that already have it? I have no problems enrolling more people after being active in the repository for a while.

[mweststrate]

Maintainer tips

Hi folks!

Thanks for the interest in maintaining MobX! Here are some practical tips and general experiences that might help to become an effective maintainer. It is not all black and white, these are just things that worked for me, but if someone else works for you, or seems better for the project, just feel free to deviate!

General thoughts

1. Not all problems require solving; many questions are quite conceptual. And it might be valuable to answer them, but it is not mandatory. Most devs are paid in the end to work their own way through a problem. Many vaguely formulated problems have their solution in either more strictly adhering to the core principles of MobX and the separation of state, effects, etc. And, on the other hand, there are edges that don't fit nicely, or don't perform nicely in the standard model of MobX. In that case people should feel comfortable in using the provided escape hatches. That is what escape hatches are for (including: not using MobX for a certain feature at all).
2. It is primarily the responsibility of issue filers to isolate and reproduce issues. Especially on a code base that is as mature and widely used as MobX.
3. That doesn't mean that MobX is bug free, but it doesn't mean either that every bug needs to be fixed. Some bugs are beyond our control (browsers), some are deliberately left there; if the edge case is too uncommon, I rather avoid having the whole community pay for a slower MobX to address the edge case of one user. This is always a balancing act. But the product doesn't have to be perfect. It should work in the expected cases and have the limitations documented. Typical case: observable on statics is not supported, even though it might work, it is not something we guarentee
4. Be prepared to take a lot of initiative as maintainer; there will be a lot of input in terms of issues and PRs, but nobody to boss you around to decide what should be solved. Always keep the interest of the community at large in mind with whatever you pick up (in terms of api surface size, bundle size, performance, backward compatibility and consistency accross different versions). Always feel free to pull in the expertise of other active community members by pinging them (in my case, if that doesn't work, PM me on twitter)
5. Answering recurring questions in the docs really pays of. I used to do that for a long time and it really brought down the amount of issues raised (or they were much more easily closed). However, the docs around 'best practices' are still pretty limited.

Practical tips

• Both new features and bug fixes should always be covered by tests
• Releasing often makes it easier. Don't worry too much about accidentally breaking stuff, reverting is easy, everybody uses lock files nowadays, and breaking something in the wild is a good teacher.
• In principle every feature and bug fix should be merged back to mobx4-master (I usually cherry-pick relevant commits for that). Exceptions are things that relate to Proxies and Symbols.
• The changelog is only maintained on master, for both mobx 4 and 5. Currently that is a manual process.

The release process

1. Review PR. Pay special notice to
   • do the docs need an update? In that case request a PR on the gh-pages branch
   • should it be backported to MobX 4? You can request a pr for that, or do it yourself.
   • are there sufficient tests?
2. Merge the PR to master. Usually I use squash (if there are conflicts you might ask to rebase, or solve conflicts yourself)
3. Push, check if CI succeeds
4. Update changelog.md, make sure to mention issues solved, the PR, the author
5. Run ./scripts/publish.js to bump the version number and publish to NPM (don't do this by hand!)
6. Go to the mobx4-master branch and cherry-pick the relevant commits
7. Push, check if CI succeeds
8. Run ./scripts/publish.js (this will automatically make sure the right npm tag is used for MobX 4!)

To republish the docs:

1. Checkout the gh-pages branch
2. Switch to Node 6.10 (using nvm) (sorry, the docs setup is really ancient and horrible)
3. Run ./build.sh
4. Commit all and push

Funds

There are some limited funds available, provided by our backers on https://opencollective.com/mobx. If you are spending significant own time on MobX on a regular basis, feel free to reach out!

... and many things more

There are probably many things missing here, I'll try to add them when they pop up in my mind!

[danielkcz]

@mweststrate Thanks for the write-up, very useful and insightful indeed.

I think we can keep NPM access currently limited to you, xavier, itamar and those that already have it? I have no problems enrolling more people after being active in the repository for a while.

What I meant is that NPM is not securely tied up to GitHub code. There has been already reported cases of stolen NPM accounts and the culprit can then easily publish a version with some extra malware code. It's very hard to track that down.

[benjamingr]

@lirantal any idea how we can do this more securely?

Honestly I can already publish very scary packages with way more downloads than MobX but I would never do that even if I was a crook because my livelihood depends on it and I'd get (sued) and am reasonably easy to locate.

As for Itamar, I know where @ItamarShDev lives and where his family lives so there's that 😃 More seriously his livelihood is also related to his web development career and his employer is decent accountability.

I don't know Xaviar well enough to say anything about him being able to publish things :]

Moreover publishing is a pain and if we can get our CI to do it (and no one else) from GitHub releases and not give anyone (but Michel) the keys that would be my most preferred option.

[danielkcz]

@auvipy #1983 (comment) or mobxjs/mobx-react#688 (comment)

[tzachbon]

Hi, I would love to be help and be a maintainer!

[danielkcz]

Come on, folks, you want to be a maintainers and you don't even read the last comment? I don't want to be repeating it for everyone... :/

[mweststrate]

Hi @auvipy @tzachbon thanks and welcome!

So far becoming maintainer has always been an organic process, and I think it is a good one. So just chime in on the issues, review PRs, create fixes or propose things. Generally we grant out further permissions on a need basis; if you're active in discussions, we make sure you get moderator permissions asap. If you'r active in the code base, you'll get repo access asap, so that you don't have to run your own fork, etc etc!

So just chime in and we'll do our best to guide you along the way! (In practice, that is honestly less than it should be, but we'll try ;-)). Some things on which help is always welcome:

• Review / follow up on PR progress
• Triage issues, make sure the proper information is surfaced, and that below par issues are closed
• Submit PR for things that are marked with the bug labels

I don't recommend to start with proposing or creating big chances; in generally we are pretty conservative in making big changes for two reasons 1) for thousands of developers things are working as they are, and we don't want to introduce very subtle changes for them 2) we want to make sure that you're in it for the long run; if someone introduces a big, very good change, but isn't there to support it, it in the end often hurts more than it helps as it forces maintenance burden on others (trust me, speaking from experience here).

If you have no idea what to pick up first, here are two suggestions:

1. There are a lot of open questions on mobx-state-tree, if you have experience with it, chime in! It is currently an underinvested area
2. Mobx-react-lite 2.0 is practically finished, but awaiting more testing. If you have an opportunity to put mobx-react-lite (or a mobx-react build with lite 2.0) in a real project and confirm it is working as expected, that would be really valuable!

Thanks!

[auvipy]

sure! i will! i use mobx on pro projects with react

[rumax]

I am looking for maintainers of this repository. That probably won't be too much of a burden (no big features in the planning), as it is mostly reviewing an occasional PR and releasing it. But there are some funds available to compensate if it is gonna cost you too much time.

Hi @mweststrate, would you be so kind to elaborate a bit more about the reason of such decision? How this will affect new features/releases, etc?

Is it still good idea to use mobx in the existing projects or we should think about migration to other solutions?

In case of a new project, what are your expectations for mobx as a project after it is transferred to new maintainers? Will it still have significant improvements, new versions or it will be frozen at the current state with only some bug fixes?

[danielkcz]

@rumax Don't worry, MobX isn't going anywhere, there are other maintainers. Michel has several other projects which he needs to split attention to, but he is still very active and we are even planning some major changes (see #2288)

[stolenng]

I would like to start contributing, what is the process of joining? :)

[danielkcz]

@stolenng Please see #1983 (comment)

[lukigarazus]

Is this still a possibility?

[danielkcz]

@lukigarazus There is always some work around here, tending to other people questions/issues at least. I recommend you to read #1983 (comment)

[Rain120]

I will try it in my free time, now I had tried to understand the code at the version of mobx 6. Fighting 💪 💪 💪

[havit1]

Is this still relevant? And if so, is this relevant for someone with no open sourse experience?

[dante01yoon]

Any open position on this? I'm interested in

[kubk]

@dante01yoon @havit1 You don't need to ask permission to be useful for the project. Please read: #1983 (comment)

[dante01yoon]

I see. Thank you

[mweststrate]

@dante01yoon welcome and feel free to chime in dante!