Open djaiss opened 1 year ago
Merging two repositories into one is a hard task, especially when we don't want to lose history of both commit trees.
What's the issue? What about having two different branches without related parent so you can import Chandler branch right into this repo.
I installed and tested Chandler a few days ago. Monica is a great tool and fun to work with, but not perfect in detail. The first impression is really great and the new structure of Chandler is the right step.
Have you considered creating a discord server dedicated to Monica/Chandler? That would be a helpful space for people to help each other in the community and make it so that "all discussion" about the project doesn't have to happen here in the Issues tracker. You don't even have to actively pay attention to the channels there if you don't want to, it can be focused around users helping each other.
I really like Monica. I LOVE how you can turn off the stuff that you don't care about using it for. Really well crafted tool and I look forward to using Chandler when that branch comes here and the migration is available. Great work all!
Have you considered creating a discord server dedicated to Monica/Chandler?
Yes, but we can't keep up with all the feedback we already receive. Do you think this kind of space would be acceptable if we don't actually contribute to it? It's already hard to find time to work on the project - if we need to maintain a new community on the side, we'll never make it alive :-)
I really like Monica. I LOVE how you can turn off the stuff that you don't care about using it for. Really well crafted tool and I look forward to using Chandler when that branch comes here and the migration is available. Great work all!
Thanks for your kind words!
Do you think this kind of space would be acceptable if we don't actually contribute to it?
A discord server can help REDUCE the feedback that you have coming into here in a good way. This project has over 18000 stars on github! You are doing this work without any serious business goals and people are noticing and recognizing your good work. You get a discord server setup and you'll have various ambassadors hanging out there.
For example: https://github.com/monicahq/monica/issues/6624
This is a perfect example of something where they user is not submitting a bug report or a feature request. Its a "support request". Channel support requests to discord where you have those Monica ambassadors that can help out and then just leave it alone.
If your concern is helping to run the discord, just think about those 18000 stars on github. There are people who love Monica that would be very capable of setting up and running the discord for you (organizing channels, recognizing people who are helpful in the community with distinguishments, etc.). Heck, I'd set one up for you just to take a look at and think about if you want me to.
Personally, I'd suggest aggressively pruning your issues and getting stricter with your minimum requirements for what comes into the issues tracker. This would help prepare for the migration where Chandler comes to take over Monica.
What help do you feel like you need most with the project right now? Perhaps I can help (I am not a heavy programmer, so don't ask me to do big stuff in laravel).
My concern is definitely about running the discord. I know @asbiin and I won't have much time to interact with the community, as much as we want to. We are just limited with our time, like everybody else. And I agree that the increasing number of issues without any answers from us is an indication of that.
Personally, I'd suggest aggressively pruning your issues and getting stricter with your minimum requirements for what comes into the issues tracker. This would help prepare for the migration where Chandler comes to take over Monica.
I think we'll prune the issue once Chandler is out, to start from scratch.
What help do you feel like you need most with the project right now? Perhaps I can help (I am not a heavy programmer, so don't ask me to do big stuff in laravel).
Marketing, definitely, and community management. Chandler's development is going well, new features are added at a rapid pace. But marketing? Community? This is the hard part for us geeks.
Also, why Discord? Is this a popular choice for developers, or OSS communities?
My concern is definitely about running the discord. I know @asbiin and I won't have much time to interact with the community, as much as we want to.
Ya, that's understandable and us community members generally want you working on the parts that are useful and interesting. Not getting bogged down trying to figure out why someones armv9 CPU isn't properly handling some php instructions or whatever else. You don't need to be active for it to be a successful community resource.
I think we'll prune the issue once Chandler is out, to start from scratch.
Do you know if github has a nice issues migration tool to move the existing issues to Monica once it is out? If not, you may want to consider moving to the Monica repo sooner than later.
why Discord?
Discord is very approachable for people to join. Many self-hosted apps use discord as their "community hub". Some prefer to use matrix chat. Both are valid, but Discord is definitely more approachable for people to join and participate in.
But discord is terrible if you are a new user. It's not searchable, to fix common issues you need to have a discord account and join a server that might not interest you. You get the same 15 questions in the channels, and can't really link to the common answer (like an existing ticket).
Discord might be great for enthusiasts, that want to show off some cool hacks/tricks/strategies they use, but it absolutely sucks as support and actively turns me away if the only way to look for guidance is a discord, even if they have a FAQ-Channel
That's the hard part about community management: You can't please everyone. Does that mean that you should avoid doing anything? Right now, Monica has hundreds of "issues". And the developers can feel the paralysis from that number of issues that are loosely structured.
So what should they try? If a discord helps a good portion of their userbase and reduces the number of incoming Issues (especially the ones that aren't even bugs), its their call whether to try it out. Similarly, if they do try it out and they feel like it is causing problems or failing to do what they hope, it is even easier to shut it back down. The devs have people who WANT somewhere to hangout. Those people are the ones that can really help the project by having conversations off github that the devs never have to see because the community can answer it and scroll on by. That's what a Discord server can help with.
Another option that the devs have is to make the Issues section dedicated to ONLY bugs. Then tags can be focused around what areas they involve or paths towards resolution. An example repo of comparable size showcases this well is libsodium. They only have a "bugs" template in their Issues tracker and the template says:
THE ISSUE TRACKER IS DEDICATED TO KEEPING TRACK OF BUGS, preferably after they have been already discussed and confirmed to be reproducible.
FOR ASSISTANCE, PLEASE CLOSE THIS FORM AND USE THE DISCUSSIONS SECTION INSTEAD: https://github.com/jedisct1/libsodium/discussions
This approach can be nice because github has an easy button on issues to convert them to discussions. And vice versa from discussions. The devs could also do a hybrid approach where Issues tracker is for all active work that they want to track. e.g. When they are actively looking to make a new feature, make an issue for it and plan out/discuss whatever they need to in that one issue. Similarly, when someone submits a bug, the Issues tracker would be the place to be. Thus, the issues tracker would be the "active" list of tasks and Discussions can be everything else. Using discussions doesn't preclude the devs from also having a Discord server if they want too.
@djaiss, this is all obviously up to you and what you like, so I leave it to you. You think about what you'd like to see and let me know if you want my help making it happen.
You also asked what other projects use discord. Here are a few links (I'm not in all of these discord servers, I just found a couple projects) in case you're curious: Calibre-web, Tandoor recipes, and Navidrome.
Many other organizations and repositories use Discord for communication. The problem is always time. It needs more capacity and a permanent moderation. Not every maintainer can offer that in addition.
At least on Tandoor-recipes' discord, the project maintainers show up there when they want to. The community ambassadors (people like me who know at least a bit) hang out there and take care of many of the questions that come in. That project only has about 4k stars on github, but the discord has about 1000 members.
If the concern is support issues versus development issues, another accessible option might be Answer (https://answer.dev). It's a self-hosted version of something resembling Stack Overflow. Has built-in moderation operations, tags and categories, and more. It's still an early project; I will have to check to see if it has Github login integration. That might be the easiest route to redirecting people to a place for support-type issues in a way that's searchable and open.
Thanks for this discussion. Just came back from a week of vacations that I really needed.
I wonder if Discord is ideal. Wouldn't Reddit be a better place? More visibility, seems a little bit less closed than Discord in the sense that posts can be public and people can help each other there?
Wouldn't Reddit be a better place?
I've been thinking about this discussion the last few days and no, I don't think that adding a reddit area would likely be helpful. Having 2 forum type areas just leads to increased noise if the users of both forums have large overlap. E.g. Most technical reddit users are very fine with using and logging into github. If you have a sub-reddit, it will be a ghosttown that has duplicate posts between it and here. Example: https://www.reddit.com/r/fogproject/ (contrasted to the main forum: https://forums.fogproject.org/).
If you're going to do anything with Discord, its going to be to do something different than your Monica issues tracker and discussions area. It would be to have an area for the part of your community that likes to be able to chat together. My theory for the downvotes that my comments have received is from people who don't want to have to go to Discord to get user support. Or don't want to be forced to use Discord. Which, frankly, seems reasonable and worth listening to.
If you want to do a better job on your issues tracker, define what you'd like to see and either start enforcing it OR empower people to help enforce it. You don't have to do it all alone. If you want to make issues only be for bugs and active development, then you'd want to create a Technical Help discussion category. And actively move items from the issues tracker to the Technical Help discussion category.
Of course, this is all kind of interesting because you're planning to clear out all your issues at some point when you migrate Chandler into Monica. Maybe your best bet to play around with all this stuff in the Chandler repo. Maybe you should seriously consider moving Chandler into Monica repo sooner than later and do the cleanup on issues.
Entirely up to you. You let the community know what you want done and how we can help.
Separate from the existing github repo that you have, you can also engage another segment of your community via Discord. I still believe that doing so would help with the incoming issues to gh, but I'm fine to leave that as a disputed point if people don't agree that it would help with your incoming work.
Discord makes it nearly impossible to reference previous answers. Instead of a single location dedicated to a topic, Discord history is a time-based events list with all active topics interleaved and smeared out across other, unrelated discussions.
Are your issue-notification emails overwhelming now? Try reading them in chronological order instead, unthreaded. This is the direct user experience trying to find existing data on Discord.
This isn't just annoying; it has the direct effect of preventing useful searches before asking, which leads to lots of negative interactions in the community.
I would second the suggestion that this is a good time to separate issues, feature requests and discussions (including support requests and everything else). Then you can point stalebot at the feature requests tag and let the community handle the discussions.
edit to add: I just learned that Discord isn't indexed by search engines. So approximately zero people will find existing answers before asking again.
I think Discord is a convenient tool that almost everyone can pick up quite easily and that a lot of people are already active on.
This makes it "better" than slack for people like me which already have a Discord account, for example, I have a Slack account for a single project, which makes me not want to use slack nor ask help in that because I don't to bother with it.
I think Matrix is also a safe bet but not many people use it, maybe the best solution would be to have a Matrix <-> Discord bridge in place. I would be happy to set it up if needed.
Coder uses a Discord for assisting users and feedback.
I think it works pretty well especially with the "new" forum channels feature. We really have managed to make it a space where it's not hard to search back for older issues because of the current setup.
I am the one administering the Codercord bot and I would be glad to port it if a Monica Discord ever opened.
Feel free to check it out at discord.gg/coder. You can create threads titled "Monica test thread" in #help and I'll delete them. I think it's worth checking out because the system we have in place with that bot is liked by our users and I think that it's honestly really good to have.
Discord now forces people to pay to be members of more servers, which means now I have to delete some of the projects I'm part of if I want to join another.
Discord now forces people to pay to be members of more servers, which means now I have to delete some of the projects I'm part of if I want to join another.
To clarify, "regular" discord users can join up to 100 (which is the historical limit anyways, I think that saying discord forces people to pay is a bit of an overstatement) servers/guilds, nitro members can join up to 200, i don't know if it's that big of a deal for most people.
Maybe the noisy discord discussion should be in another issue since this issue is about chandler.
Any word on when we can expect chandler to be merged into main and officially released? I'm excited
Chandler Beta is launched today 🥳 See this post https://www.monicahq.com/blog/chandler-is-in-beta
Hope you will like it.
Also, sorry for all the bugs we've seen in production, folks. We are actively looking into them.
Are there any self-hosting examples for Chandler? I tried looking for docker-compose files in the chandler
branch but I couldn't find any
Same, Chandler in the original repo had an option to use docker to host, as well as instructions on how to do so but I don't find anything in the chandler
branch.
Would also like a hint how to setup chandler especially with sqlite via docker-compose
Would also like a hint how to setup chandler especially with sqlite via docker-compose @pl33x
Just insert the GitHub docker image ghcr.io/monicahq/monica-next:chandler
from https://github.com/monicahq/chandler/pkgs/container/monica-next and rest is like 4.x monica
version: "3.4"
services:
app:
image: ghcr.io/monicahq/monica-next:chandler
depends_on:
- db
ports:
- 8080:80
environment:
# see https://github.com/monicahq/monica/blob/chandler/.env.example
- APP_ENV=production
- APP_DEBUG=false
- APP_KEY=secret
- DB_HOST=db
- DB_USERNAME=monica
- DB_PASSWORD=secret
- MAIL_MAILER=smtp
- MAIL_HOST=smtp.server.com
- MAIL_PORT=465
- MAIL_USERNAME=email@username.com
- MAIL_PASSWORD=secret
- MAIL_ENCRYPTION=tls
volumes:
- data_chandler:/var/www/html/storage
restart: always
db:
image: mysql:5.7
environment:
- MYSQL_RANDOM_ROOT_PASSWORD=true
- MYSQL_DATABASE=monica
- MYSQL_USER=monica
- MYSQL_PASSWORD=secret
volumes:
- mysql_chandler:/var/lib/mysql
restart: always
volumes:
data_chandler:
name: data_chandler
mysql_chandler:
name: mysql_chandler
Would also like a hint how to setup chandler especially with sqlite via docker-compose
Here's how I do it with MySQL, you should be able to get rid of the db
container and use some env variable to tell it to use SQLite instead.
version: "3.9"
name: "chandler"
networks:
default:
external: false
ipam:
driver: default
config:
- subnet: 172.34.0.0/24
volumes:
db:
data:
services:
db:
container_name: monica_db
image: mysql:5.7
environment:
- MYSQL_RANDOM_ROOT_PASSWORD=true
- MYSQL_DATABASE=monica
- MYSQL_USER=${DB_USER}
- MYSQL_PASSWORD=${DB_PASS}
volumes:
- db:/var/lib/mysql
networks:
default:
ipv4_address: 172.34.0.3
restart: unless-stopped
monica:
container_name: monica
image: ghcr.io/monicahq/monica-next:chandler
environment:
- DB_HOST=db
- DB_USERNAME=${DB_USER}
- DB_PASSWORD=${DB_PASS}
- APP_ENV=production
- APP_URL=${MY_ACCESS_URL}
- APP_TRUSTED_PROXIES=*
- MAIL_MAILER=log
volumes:
- data:/var/www/html/storage
networks:
default:
ipv4_address: 172.34.0.2
links:
- db:db
restart: unless-stopped
Hello there 👋 What is the recommended way to contribute to localization? I think I found two possible ways to do this;
lang/ja/*.php
or lang/ja.json
I've done some translations on crowdin. Many thanks in advance ❤️
@djaiss even though monicahq/chandler was closed, will the issues in it be addressed?
thank you
Is there an FPM version of the chandler image? I'd love to be able to just swap it into my existing docker-compose file that is built on 4.0's fpm image.
For anyone who is self-hosting ~monica~ chandler. Does your Available modules:
have some modules or it's empty like me ? This makes the self-hosted version unusable :(
@vnghia are you sure this is monica? Is this already chandler? I am hosting monica 3 myself but this is not looking like yours.
Ah sorry, it is about chandler. Basically I can get it up and running but it is not usable and I can not create any modules or so. I would like to ask how is your experience with self hosted chandler so far ?
@vnghia I had the same experience. No templates or modules by default.
Ah sorry, it is about chandler. Basically I can get it up and running but it is not usable and I can not create any modules or so. I would like to ask how is your experience with self hosted chandler so far ?
Could be a missing database connection. Enabling debug mode can help. At start I had "missing migrations" messages until I correctly setup the database.
All my migrations are done and I can add new contact. But I can not configure the template to show information about these contacts and I only have their name for now :/ One more thing I found out missing is the list of currencies which is also empty. My current database is Postgres
if that helps.
P/S: I tried Mariadb and it is not working either.
Would also like a hint how to setup chandler especially with sqlite via docker-compose @pl33x
Just insert the GitHub docker image
ghcr.io/monicahq/monica-next:chandler
from https://github.com/monicahq/chandler/pkgs/container/monica-next and rest is like 4.x monicaversion: "3.4" services: app: image: ghcr.io/monicahq/monica-next:chandler depends_on: - db ports: - 8080:80 environment: # see https://github.com/monicahq/monica/blob/chandler/.env.example - APP_ENV=production - APP_DEBUG=false - APP_KEY=secret - DB_HOST=db - DB_USERNAME=monica - DB_PASSWORD=secret - MAIL_MAILER=smtp - MAIL_HOST=smtp.server.com - MAIL_PORT=465 - MAIL_USERNAME=email@username.com - MAIL_PASSWORD=secret - MAIL_ENCRYPTION=tls volumes: - data_chandler:/var/www/html/storage restart: always db: image: mysql:5.7 environment: - MYSQL_RANDOM_ROOT_PASSWORD=true - MYSQL_DATABASE=monica - MYSQL_USER=monica - MYSQL_PASSWORD=secret volumes: - mysql_chandler:/var/lib/mysql restart: always volumes: data_chandler: name: data_chandler mysql_chandler: name: mysql_chandler
Anyone know how to get this running on a raspberry pi (armv7?)
Anyone know how to get this running on a raspberry pi (armv7?)
Update to 64-bit OS. Rapsberry Pi 3 B and everything after is 64bit capable.
It took me a while to get the database connected correctly, I had to set these env variables to store everything in mysql instead of sqllite database.
DB_CONNECTION=mysql
DB_HOST=monica-db
DB_DATABASE=monica
DB_PORT=3306
DB_USERNAME=monica
DB_PASSWORD=secret
Does anyone have a working docker-compose.yml and .env file combination? I tried replacing the image url of ghcr.io/monicahq/monica-next:chandler with ghcr.io/monicahq/monica-next:main, but I’m still getting “server error” issues when trying to access the url.
Is it still possible to work with the 5.x version of Monica? Whenever I run the docker compose with the url of ghcr.io/monicahq/monica-next:chandler it "manifest unknown" errors out and when using ghcr.io/monicahq/monica-next:main it deploys the 4.x or stable release. Love to try the Chandler version in docker but I'd love to learn where to find the image?
Please find the Monica 5.x beta 3 here: https://hub.docker.com/r/k714040/monica
I'm getting increasingly anxious about the future of this project :(
Does anybody have a line to the core maintainers? It would be great to know if they need the community to step up and help out a bit more. Worst case maybe we could set up a functioning fork that has some CI / CD so we can start adding features / fixing bugs for home setups until the maintainers are back in action?
Hi all.
Original author here. My comment below is not an excuse, it's an attempt to explain my thoughts as honestly as possible, and it won't be super structured.
I know we've been silent on this project for a while. It's incredibly taxing to maintain a project that huge, especially considering the fact that we have a job, @asbiin and I. @asbiin has been an amazing partner on this project, and I'm thankful he's there, and if the project is where it's at right now, it's thank to him.
I think, personally, I got burnt out and got through terrible mental health issues related to open source. 2023 has been a very intense year. Much more responsibility at my job, I got married (🎉), I got fatter because I don't take time to do much sport. I got caught up in a vicious cycle: every time I checked my Github notifications, I realized how much attention this project needed, and it's stressed me tremendously, so I closed the tab (on Firefox, because Firefox > Chrome, obviously 😅). Rinse and repeat. And this is where we are now: a project that feels abandoned despite having a great community.
After a few months of thinking, on the v5 redesign, I think I got carried away of wanting to do too much. All the customization possibilities, all the possible use cases, a much larger scope than the first version of Monica. The software is now much bigger than what it needed to be originally. I'm still proud of what we've done with v5, I think it has a tremendous potential, even though we still have a lot of bugs. But by trying to be an all-in-one CRM, nothing is "wow" because everything is half baked. It's not ideal. I now would prefer a much smaller software that does a few things very well instead.
Also, one more reason about why I got burned out. The need to migrate data from the Monica to Chandler. It would take so much time to implement this, for basically a one-time action. At the current rate of what we can do, this is at least a three months job, at the minimum. Just thinking about this feels like the worst part of a daily job. Something that do not bring any joy. My current feeling is that I should let the current state of Monica v4 as it is, make it read-only, sunset the product on our hosted instance, and simply launch v5 (aka Chandler) as if v4 doesn't exist, and therefore, don't migrate data. We have so many users on our hosted instance, but since we do not have analytics, I'm not actually sure on how many active users we have. I don't know exactly how they will like this though.
All this to say that the project has become way too big for only two maintainers with full time jobs "on the side". If we were full time, I think it would be okay, but that's not the case.
Basically, we need help. On several fronts:
If I didn't want to ask for help before, it's because I've seen a lot of people motivated by the project, wanted to do something, and after a few days, disappeared.
So what must be done?
Repository maintenance
v1
(https://github.com/monicahq/monica/labels/v1) so we know we can close itOn the code
Believe it or not, we care deeply about Monica. We've put our souls into it for many many years. We are at a stage where we need your help. Without the help of the community, the project has a 100% chance to fail in the near future.
Help us build the future.
Congratz on getting married, @djaiss! We all are so happy for you. We love this project and we are very thankful for the work that you both have put into it.
I'll reference my comment from a year ago:
Personally, I'd suggest aggressively pruning your issues and getting stricter with your minimum requirements for what comes into the issues tracker. This would help prepare for the migration where Chandler comes to take over Monica.
257 of your 662 open issues (~30%) are feature requests. ~50 of your 662 are bugs. The other 300 items have some other label, or no label at all.
When I think of community management and your ideal community managers, I think of deputies who HELP you out. Who make things more manageable for you. Who help to enforce standards and organization. Now what they are doing, is up to you.
You said that you want your issues to be tagged as <v5 and v5+ so that you can close everything that is <5.0.0. And you say that you want to identify what is in-scope for a viable 5.0.0 release. That's where you need to be using a project. You've already done similar for v3 I can see. Get your community managers to set that stuff up and you can guide and refine. Stuff like this is CLEAR and easy for your community managers to follow.
But issues starts to get sticky when community managers don't really know what you want to see.
You have to pick whether you want feature requests in here https://github.com/monicahq/monica/discussions/categories/ideas or just as a label in your issues. There are pros and cons to either one, but using both seems less than ideal. Using discussions is nice because people can upvote ideas and you can sort by most upvoted ideas to see what features the community really wants. But ideas don't really get indexed by google like issues do. So if you want people to be able to find an idea by google, you need to use issues instead.
If this were my project and I wanted to switch to using discussion ideas, I'd seriously consider having someone convert all feature requests to your "Ideas" discussion category. Again, the ideas category is nice because people can thumbs up the idea and you as a developer can sort by "most thumbs ups" at the category view. I'd seriously consider tagging the people who have previously thumbs upped (upvoted) the feature request so they know to come to the discussion idea and now thumbs up the idea. And if you want to maintain your own list of ideas that you are considering adding but want them separate from adding each one individually in the ideas category, maintain a roadmap document with those extra items as wishlist features you would like to implement. But your default idea place should be the ideas category so that people can individually upvote ideas and you can be empowered with the community feedback.
Talking more about the cons of this approach, the primary one I see is that they aren't well indexed in google. Searching "monicahq Immich integration" has the top result of: https://github.com/monicahq/monica/discussions/categories/ideas. Why doesn't it take you straight into #7116 ? Why doesn't google have that indexed? You have to use the search tool within github to find it. Do you like being able to sort by top ideas more than you like it for people to find individual ideas easily? If you have a community manager, they could use labels to review every incoming idea and search for something similar to direct the user to. You could even have every idea also have a github issue item as well. That's quite a bit more work, but maybe its what you'd really like to see happen. I dunno.
Now, these are just some of my quick thoughts. I love this project. I'll happily volunteer to be a community manager that works to make github more useful TO YOU. If we get you setup with a project roadmap for 5.0.0 and you like the list of features, then all you have to do is hit those items and then you are done and can officially release 5.0.0. Simple as pi :D. There are others who would also be willing to be community managers besides me, by the way. But as far as I'm aware, you haven't ever put out a call to ask who is willing to take on these responsibilities. There is a certain level of trust since they can screw things up, so don't just make everyone a maintainer, obviously.
Lastly for now, I think you need to be willing to setup some extra help for your community managers. Whether its typing up a doc on specifics that you want them doing, or getting a voice call with them sometimes, or setting up some chat channel that you can use to communicate. They need help knowing when they are doing stuff right or wrong (and changes are needed). A little feedback from you towards the community managers will enable them to really help you out.
Edit: If you do add me as a community manager, please understand that I won't necessarily be doing much for the next 3 weeks. I'm currently preparing for a presentation for a devops conference in Washington state the 2nd week of April.
So much love to you @djaiss! Please know that we're here for you, and that there is no shame in the amount of tasks there are to work on (including PRs to review). I know exactly how you feel.
I would be very happy to be involved in any of the following:
1) issue pruning and PR review 2) community management and communication (I'd be thrilled to work on a team with folks like @Szeraax to facilitate this, and could imagine there being value in hopping on a video call / even setting up a regular community call. Maintaining a project board and communicating roadmap / priorities based on conversations would be great. 3) I will be glad to commit code over time as well of course, as there are features I'd like to help build, but the first two feel most important in the short term.
FIWW: I do agree that it's reasonable for you to focus on v5 and call v4 static for now. The community can help build an importer if that is valued.
@djaiss Merci beaucoup d'avoir fait le point. Prend d'abord soin de toi, je sais tellement à quel point l'open source peut consumer une vie (et je suis pro logiciel libre/open source depuis 30 ans).
Je pourrais écrire quelques scripts pour fermer des issues en batch. Quand à la migration, peut-être qu'un third party pourrait s'en charger? À part votre hosted monica, as-tu une idée comment c'est populaire, ça touchera combien de gens ce reset?
Thanks for all your feedback! @asbiin and I appreciate it a lot.
We'll discuss he and I over the next few days to check how we will proceed to onboard the ones who want to help us. I think we will prefer a way of asynchronous communication instead of calls - we already have too many Teams calls all day long 😅
I'm investigating the route of teams within the organization but I think Github doesn't like team communication since the UX is atrocious there. We had a Slack in the past but I'm afraid of the noise there. Any ideas on how we could communicate in this future maintainers group?
We should write in English here so everyone understands 😅
Je pourrais écrire quelques scripts pour fermer des issues en batch. Quand à la migration, peut-être qu'un third party pourrait s'en charger? À part votre hosted monica, as-tu une idée comment c'est populaire, ça touchera combien de gens ce reset?
Last time I checked we had ten of thousands of self hosted instances out there. But I don't think it'll be an issue for those people. I think it's worse for us to maintain two hosted versions: the current one with 45k+ users, and the new one with already 2500+ users.
Any ideas on how we could communicate in this future maintainers group?
We can use a discussion, honestly. You already have that space enabled in the repo, so its not like you have to setup anything fancy. Or slack/discord/email.
Hi. Monica's team here.
The project is not dead. Far from it. In fact we've been working for a year and a half on Chandler, the code name of the brand new major version, and we push new code almost daily.
It's available here: https://github.com/monicahq/chandler
Since Monica is still a side project and we have full time jobs and families, we can't answer all the issues that you all create, even though we read them all. We need to prioritize what we do in our limited free time. This is why we put all our energy in creating a brand new experience with Chandler.
Chandler will address a lot of problems Monica has. Not all of them, but we hope it'll make you happy. It's also heavily unit-tested so we hope there will be less bugs. The dev stack remains mainly the same (Laravel (PHP) + VueJS + Mysql/SQLite/Postgre support), but we use Vue throughout the entire app, not just in some cases like we currently have in Monica. For the curious we use https://inertiajs.com to make it possible to use Vue with Laravel. Using Vue for the front end makes a user interface that feels really fast. The UI is also cleaner and more modern, while being sober.
We plan to move Chandler's code to this current repository. Why?
Merging two repositories into one is a hard task, especially when we don't want to lose history of both commit trees. That'll be fun to do.
Before launching Chandler officially, we need to finish an exporter/importer. Chandler's codebase and data structure is completely different from Monica's. Right now, you couldn't import Monica's data into Chandler, so that would suck. We know it's an issue.
Chandler will be more focused on documenting your life, than being a personal CRM. While we kept most of all the current features Monica has, we've put a lot of effort on the journaling/personal diary feature. I mean, a lot of effort. Honestly I think we'll have one of the best journaling system out there and we really hope you'll like it.
So, please be patient. We'll post a new issue when Chandler is ready for testing.
With a lot of love, @djaiss and @asbiin. Thanks for being part of this community.
Below are some screenshots of Chandler, filled with fake data.