A vision for CodiMD

[SISheogorath]

Here we are! CodiMD is running in an own organization. Hard forking is usually the last resort for an open source project, but we felt that it was neccessary for continued development and the future of CodiMD. If you wish to read up on the final debate that lead to this, please refer to the old bug tracker.

It's time to stand together and find our way through the jungle. In some regards, we are back to zero, and that's sad. But on the bright side, the issue tracker has a lot room for your problems! 🎉

Let's work together!

The new GitHub organization provides us with all the flexibility we need to work on our own terms. We already sent out invitations to various community project participants and will welcome people to join us.

You might wonder about the next steps. We currently rebuild the infrastructure parts that were in the hands of HackMD, like the container repository, and work on integrating services with our new home, which was previously more difficult.

With this done, we look towards a very interesting future:

One of the first actions we'll take is providing a fully documented and working API for CodiMD, which should allow you to import, export, create, delete and even modify your notes. You are welcome to participate in the debate about the API design.

APIs are great, but your eyes deserve some love, too: So we also started working on some UI/UX improvements. User Profiles will be continued and completed over here.

Finally, we also want to work on improving the connections and collaboration within the community. Our community forum should be up in a few days is up.

I'm looking forward to your ideas, inspiration and comments. Let everyone know, that CodiMD is not dead, it's reborn!

[SISheogorath]

QA

Do I need to change anything to run the new version?

Yes, you might need some changes for your next update.

Native setup using git:

Change the upstream remote using git remote set-url origin https://github.com/codimd/server.git.

Docker:

When you use our container repository (which was previously codimd-container) all you can simply run git pull and your docker-compose.yml will be updated.

When you setup things yourself, make sure you use the new image: quay.io/codimd/server.

Heroku:

All you need to do is disconnect GitHub and reconnect it with this new repository.

Or you can use our Heroku button and redeploy your instance and just link the old database again.

Do I need to change anything when I was using the codimd-cli or codimd-container repository?

No, those repositories were moved. This means github takes care. But feel free to use git remote set-url origin https://github.com/codimd/cli.git and git remote set-url origin https://github.com/codimd/container.git

What happens to the old repository?

We don't know. This is no longer in our hands, but we wish for the best.

How to move my old PRs?

First of all you need to fork this repository. Then you use git remote set-url origin [email protected]:<your username>/<your fork name>.git (e.g. git remote set-url origin [email protected]:SISheogorath/codimd-server.git) and then run git push --all. Now you can just re-open your PRs from your new fork to this repository.

What happens with the old issues?

Please use the space we got and re-open them. In order to keep the history of the issue, please include a link to the old issue.

Is there a way to hear/see more?

We are planning a community call for the 7th of April. More details with follow soon. Usually the happen around 8pm CEST, please each out to us, if this doesn't work for you, we'll try to find a solution.

What about my notes on the demo instance?

The demo instance is part of the community infrastructure and therefore not affected by any of those changes. We made sure things are setup with the new repository.

[gramakri]

Just learnt about this big change, thanks for continuing this work! From the Cloudron side, the CodiMD app will continue to follow this repo. We had already changed the name a few releases ago - this commit. I am just fixing up our package to use the new 1.3.2 release that was made some hours ago.

[MartB]

Whats up with the other organisation?
Why are there frequent updates atm i thought its abandoned?

[SISheogorath]

@MartB The old repository is continued by the original HackMD team, according to their statement. There is currently not so much activity over here, because I'm quite busy right now, but will dedicate some more time to it in September. Every contribution is very welcome and I'll take some time to review it, when they come it and also try to merge things. It's just that I have no time right now to write own features.

[zeigerpuppy]

Viva the open CodiMD.

One thought, would it make sense for us to have the project in a Gitlab repository rather than Github? It may be the only chance to make that change.

It just seems more natural to have the project live on a Gitlab repo considering that CodiMD integrates so well with the other components of that ecosystem.

If there's support for a shift, I'd be happy to provide hosting resources if they're needed.

edit... note that it looks like I'm a bit behind the times on this!

[HerHde]

@zeigerpuppy Great idea, but that was discussed earlier, when MS acquired GH. The voting result was quite even.

Though I guess there are a lot of GitLab CE users, hosters and fans here, including Sheo and Claudius (and even my humble self), Claudius politely declined that proposal when I offered it.

[zeigerpuppy]

@HerHde Thanks for pointing me to the discussion. And a reasonable outcome for the moment too.

[SuperSandro2000]

GitLab has no discovery so we would lose on a lot of potential new users and they would probably just find the codimd of hackmd.

[almereyda]

We are using GitLab's "repository mirroring" functionality to keep issues and MRs in GitLab, and push changes to GitHub on any push. That also allows us to integrate with the automatic Docker Hub pipeline. So we use GitHub for visibility and discovery, and GitLab for work. Ref.: - https://lab.allmende.io/wirvsvirus/lefat/lefat-backend - https://lab.allmende.io/wirvsvirus/lefat/lefat-frontend - https://github.com/lefat/lefat-backend - https://github.com/lefat/lefat-frontend

…

On Sat, 11 Apr 2020 at 23:44, Sandro ***@***.***> wrote: GitLab has no discovery so we would lose on a lot of potential new users and they would probably just find the codimd of hackmd. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMRV7B2NK3OXOGFPZCM7U3RMDQFTANCNFSM4HCEUEKA> .

[zeigerpuppy]

That's great to see, and thanks for the remindier about the repository mirroring feature, really useful for us lovers of GitLab!

[SISheogorath]

So I wanted to give everyone some space to express their opinion before I jumps Ingo this discussion, because as maintainer it might stops some people from expressing themselves when they already see "there seems to be a official decision".

As some people might know, I'm definitely in favor of self-hosted solutions, BUT as we already mentioned in the previous repository, we should look at what suites out community best. Right now, the influx of new people seems quite good and people seem to enjoy hanging out here. I would like to avoid breaking that. And given that we will also rename in a foreseeable future it'll make a lot of things more difficult when we also change the repository at the same time. (Not to mention that GitLab really isn't great for SEO, sadly)

On the other hand there is the hybrid approach that @almereyda mentioned, but that opens a bunch of problems. Gitlab CE is not made for fork/edit/MR workflows. You neither get CI runs in your own namespace for a MR of a fork, nor do you get a MR for the actual merged version. Which makes it much more complicated to asses if merging something will break your master branch.

All in all, what speaks for hosting it off GitHub:

• We could use free software
• We might enable people who refuse to use GitHub to contribute
• we wouldn't have downtimes when GitHub is down

What speaks against it:

• We would lose a lot of SEO
• We would break the current influx of new contributors (most likely)
• We would increase the complication of contribution by requiring new accounts
• The CI features wouldn't fit our development workflow

Exception: Sourcehut.
Here the requirement of an account could be removed, but it would force us into a Mailinglist-based development workflow which I don't think people would be willing to do.

I'm very open for critique of my just wrote together piece, because maybe I have a complete misassumption of what is going on.

[zeigerpuppy]

@SISheogorath really good points.
From my perspective if a project can be done with free software it's always a bonus. I guess the situation with GitLab/CodiMD is also a special case. It would mean we could use the GitLab/Mattermost/CodiMD integration in the process of further development (which may also lead to new use cases and tighter interoperability).
But I don't believe in changing platforms if it means that the workflow will be much more difficult. Ultimately I think that's a decision for the key maintainers.

Losing SEO and discoverability are certainly big issues.
But the main issue you've raised of the different merge workflow seems to be an even bigger problem. I didn't realise that GitLab/GitHub were so different in that regard.

[pirate]

FWIW, I would be unlikely to contribute to a GitLab or mailing-list based development workflow simply because I never interact with that site, and most of my interaction with CodiMD happens organically on Github when I notice I have notifications. I suspect this is also the case for many other casual CodiMD contributors over the years. I'm by no means a core contributor to CodiMD, so don't let me sway the overall opinion much, but I do want to contribute myself as a datapoint in the overall discussion.

[ccoenen]

I'm very torn on this one. On the one hand, we're creating a huge single point of failure with a centralised entity. On the other hand, I do also like the benefits a one-stop-shop like Github or Gitlab brings. I still have ~50 accounts on various bug trackers and forums from ye'olde times when every project did this for themselves. That was no fun at all. I rarely go to these lengths today, to be honest.

So, there I have it. Complete conflict of What I want to have and what I actually do. 😕

[ccoenen]

Single point of failure in my post above refers to multiple things. I'm not only talking about "github might go down", but also to the way they do business, the rules they enforce, the general power they have over open source, just by basically enabling or disabling whatever or whoever they want.

[SISheogorath]

With the HedgeDoc renaming on the horizon and further work towards 2.0, I think we can close this in favour of the big orga board for 2.0 which will summarize and show way better what HedgeDoc will become. 🙂