🔔 Update on the project #6626
Comments
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! |
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 :-)
Thanks for your kind words! |
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: #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.
I think we'll prune the issue once Chandler is out, to start from scratch.
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? |
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.
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.
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:
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? |
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. 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. |
|
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 |
|
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 |
|
Would also like a hint how to setup chandler especially with sqlite via docker-compose |
Just insert the GitHub docker image 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 |
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 P/S: I tried Mariadb and it is not working either. Below is the log of my server |
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
On 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:
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:
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 😅
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. |
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. |
|
Totally makes sense regarding the preference for async. Some thoughts, in no particular order, regarding communication:
I don't know if this tool would address the noise concerns, but one thing it definitely has that's better than Discord / Slack is that streams can be set up for "global read" which mean conversations can be linked to / read by people without an account. This is a nice way to avoid Discord Knowledge Rot, and I've found it to be a bit more suited for FOSS.
(I vote starting with using the existing discussions since it's the lowest overhead, and falling back to email for anything that requires privacy. Can evolve from there) |
|
Hey all, first of all thanks for the heads up @djaiss. I'd be glad to help where I can but we should probably take this to a more immediate type of discussion (e.g Discord, Slack, etc as already mentioned by others) to organize better. Regarding the platform to use, I don't know if Zulip is a great choice, last time I used it I really hated the UX, maybe it changed though. I think Discord is fine since a lot of FOSS communities are already on it but I think the best thing to do would be to set up a poll somewhere so we can decide on what to use. |
|
Thanks for the heads up @djaiss ! I'd love to help as I'm an active user on my self hosted v4 instance, and would love to run my own v5 instance. To avoid multiplication of communication channel, I'd rather stay with a Github team inside the MonicaHQ organization and an asynchronous communication (also it would be easier to link issues/PR from my perspective), but if the majority of the community move somewhere else, I'd join the majority. When this decision is made, I'd like to help to create bug report/testing the v5 and help through the self-hosted part. |
|
just a comment regarding communication: use discussions, it's like a self building documentation, and a good place to move issues to that are not issues. |
|
@djaiss first off, thank you to both you and @asbiin for all of your hard work and your vision to create Monica. I'm an Aspie myself and this is the tool I've needed for so long and I want to help in any way I can. I'm not a coder (I only know enough to be dangerous lol) but I can help with beta testing, brainstorming ideas/processes, sorting through issues, anything I can do to help I'll do my best. I am self-hosting v4 currently. I also agree with @whysthatso about using GitHub discussions. I frequently turn to the issues and discussions tabs when I'm troubleshooting issues. |
|
Hi im a little bit confused, is chandler now life? wouldnt it be than a good idea to close these issue? or is there an point in still letting it open which i dont see? |
|
Hello @djaiss, after reading this comment I am very sorry for what happened to you, I do not have such a large open source project but I can understand everything you say. It's a shame that despite having a project as cool as this and such an incredible community, you can't dedicate yourself 100% to the project. I recently launched a project called Opire that makes it easy to create rewards to solve issues, the good thing about Opire is that anyone can create rewards (not just you) in such a way that the community can economically help evolve the software. This way we can encourage other programmers to want to solve these issues. There are more advantages of using Opire that you can see in the documentation if you are interested. I know this isn't going to solve all the problems but at least I hope it can help a little. For now, I would like to put $100 through Opire in the issue that you consider best. |
Opire's co-founder here, and also an Aspie. I didn't know about this project before, but I can totally understand how it has been able to help other aspies and introverts folks. Discovering it has been great - I will totally try it out. I just had a very bad experience not remembering a neighbor's name and I had to deal with anxiety for a week cause of him getting mad about it 😅 I wish I had discovered Monica sooner. I would like to contribute to Monica. As a developer (with some experience in PHP & Vue) I could help with the code, but realistically I already have too much in my plate, and you already have bad experience with people motivated about helping that end up disappearing. I could tackle some bugs and help with small maintenance issues, but definitely I can't compromise to be a proper maintainer - I just don't have enough time. However, I'm willing to help by creating rewards myself in issues that you / the community consider as priority. Especially looking forward for those issues that will help to reduce the amount of attention that the project requires (bug fixes, maybe?). It's not a lot, but I would be able to put around ~$100 per month into funding rewards to encourage others devs to solve the issues. I saw you have a Patreon. If you don't want to install Opire, that's fine - I'll set up a monthly donation to your Patreon. But I would prefer to fund specific issues to increase the amount of devs collaborating and reduce the pressure on you. |
|
After this week's report of a year's long takeover attempt that was thwarted by a microsoft employee on xz utils, everyone in the open source world is probably scared of anything that looks like coordinated pressure on open source anything. Monetarily, socially, etc. If you don't know what I'm talking about, go read this horrifying story: https://www.theverge.com/2024/4/2/24119342/xz-utils-linux-backdoor-attempt Not trying to knock on opire specifically (never heard of it), but I'm just leery of external influence, especially recently. |
|
Totally understandable @Szeraax! However, tbh I'm glad the backdoor was tried through open-source - at least that way people like Andres Freund (the Microsoft employee) can check the source. Imagine if this was done in private code - the person/group behind the backdoor could have perfectly infiltrated an employee in the company to make the changes without going unnoticed, and then if someone realized about the 500ms lag they couldn't have investigated what caused it Anyway, that's just my personal opinion - I still can understand everyone being scared |
|
@djaiss @Szeraax I'm not sure if y'all started coordinating off line but in the event that it would be helpful to coordinate anything outside of this thread (in lieu of setting up discussions), my email is I'd be glad to work with @Szeraax to help implement the setup of some discussion categories; I think the first step would be just taking a moment to level set on what your expectations would be @djaiss and how we can help things feel less overwhelming on your end. |
Hi @Szeraax I totally agree, I understand the concern and distrust (especially in a project that we have just launched) but to be fair we do not make changes directly to the code (nor do we want to influence what changes are made to the code) or even we do nothing that doesn't already exist, there are competitors like Algora.io or previously bountysource that do something similar. What my colleague and I said is completely true, we want to help the project not only monetarily but also encourage issues to be solved since it's one of the problems that the maintainer mentioned and we simply believe that this tool can help and is the best for it. Anyway, it was just a suggestion 😄 |
|
I have no authority here, so please don't think that my voice matters any more than yours does. What happens is up to the developers. Personally, I'm more interested in the comment by Slifty about updates on community management and hearing how the developers think the community can help them with the community management side of this awesome project. |
and others
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.
The text was updated successfully, but these errors were encountered: