A forum is a better way to discuss ideas

[sandroden]

I want to report here some of the ideas I have on how a community should carry on discussion and ideas.
Currently, ankiommunity has just a chat (gitter) that (as any other chat) has many flaws:

chat

1. Threads are mixed up. This one alone makes it the worst plague sent by some evil entities in the quest to set discord on humanity...
2. You have visibility as long as you're the last one... It's enough that someone writes (possibly a minor issue) and you're deemed to forgetfulness (sad fate for a bunch of developers addicted to memory empowering tools *:-)
3. No search tools
4. No possibility to link a discussion or a passage or something
5. No way to move an interesting discussion elsewhere, unless you re-write everything (I'm partially doing this now, I did it for the docker-compose remarks): it's acceptable just in the hope of a "better world", not as a finale "modus operandi".
6. No clear possibility to tag chat (eg: I'm interested in djankiserv, not in anki-sync-server)
7. No way to trace the "last word" on an argument

Issues

So the only possibility is to use "issues" split over a bunch of repositories so that you don't have a clear view of what is being discussed.

1. If I open an issue on a "wrong" repo, there's no way to move it to a proper place.
2. You're not correctly informed of new issues and discussions tend to mix-up with technical issues in an unnatural way.
3. No search site-wise
4. No tagging (I may be wrong here, but nothing usable site-wise anyhow)

I don't want to put you off contributing. So if I could understand what in particular you want to talk about, I could understand your position better.

I may be wrong but this group could potentially grow and entice more people that would undertake a big effort to get the hang of what is going on, what has been done, which is the status of the different projects (the latter can in fact be solved by the wiki, honestly). I don't know which is your goal but if we have a good synchronization server with usable API, many ports would open up and this could really become a place where talking of many technical challenges. You don't want to do it on a simple chat + issues.
Ankicommunity is not the only group that has these needs, so why not take advantage of what other groups have already developed?

forum

A forum like discourse can help as it has a slew of features developed exactly for this:

• categories (eg: djankiserv, anki-sync-server, wiki, API, addons, frontend...)
• tags (eg: schedv2, docker, container, milestone, presentation of us, github... )
• search site-wise (with tags, categories, ...)
• notifications in a gazillion possible ways (mail or not, silence thread, category, ...)
• post that can be repositioned to be on top (eg: welcome, request for help...)
• post that can be edited after push (with history of the changes)
• post that becomes wiki (keep history, easy as writing a post with markdown)
• configurable menu to set links to most important pages / repos
• groups and permission to a fine grade
• bookmarks system for your preferred links
• polls. Each post can contain any number of poll
• reactions: you can react to each post, that can be a convenient way to understand how an idea is appreciated without cluttering the thread

CONS: (to me) exaggerated social attitude (nice to thumb up a nice post, but I can't stand all the badges it gives any time you do something)

No need to abandon gitter for rapid chatting and to be sure we can address people from gitter to the forum.

So, what would be the downside? I bet we would probably entice more people to join this group, that would get the feeling of an organized group. I'm pretty sure you'd get acquainted pretty fast. If you have visited Anki forum. The advantages are not just for bigs, believe me.

[kuklinistvan]

Hello,

I'm leaving this here for the record: we had another proposal (#5) that we should move from Gitter to Discord . Although I can be easily sold on that in the long term as I see its advantages, you may also noticed that I was more confident when it came to creating another forum instead.

The reason is that while Discord would be a replacement for Gitter in my understanding, and thus would force people to move (or at least we could end up in a strange situation where we both have Gitter and Discord, increasing the chaos), creating another forum with the features above could be populated with our current crew gradually from Gitter. If a discussion gets intensive on the latter, it always could be continued in that forum, but nobody would be forced to look for us again at another place.

Therefore, I would begin our communication upgrade plan with the forum, and somewhat later we could prepare to move to Discord.

Also, after our upgraded infrastructure is set, I will create another page on the wiki explaining our means of correspondence.

[VikashKothary]

Hi,

Sorry in advance for the long reply.

Thank you for your suggest. As @kuklinistvan said, this is the second of these tickets which suggests changing our tools. I think there are pros and cons to this proposal which I will try to discuss here.

But before we do this, I'd like to better understand the problem we are trying to solve. I've broken down the existing tools and the type of communication they are trying to cater for.

No need to abandon gitter for rapid chatting and to be sure we can address people from gitter to the forum.

1. Glitter is for real-time communication

As you've stated, we need a chat app for real-time communication. The purpose for chat apps is not to hold long threaded conversations (even though some do) but to allow for quick and short message transfer. So for this ticket, I don't think we should discuss Chat Apps. If you wish to discuss Chat apps, I'd suggest moving your points over to this ticket: #5.

Currently, ankiommunity has just a chat (gitter) that (as any other chat) has many flaws:

2. Github Issues is for technical communication

So Glitter is a recent addition when it comes to communication. But first and foremost, all technical communication goes through Github Issues. I think you would agree with this. I think one point we need to align on is what constitutes techincal communication. My opinion is that Feature Requests and Bug Features count as technical communication and all discussion and ideas around them should be done on Github Issues. You make a valid point, there's no way to get visibility across all the separate projects and that is something we definitely need to solve. Is that the problem you want to solve?

post that become wiki (keep history, easy as writing a post with markdown)

3. The Wiki is for business communication

As one of our newest additions, the wiki is where I send any ideas and discussions regarding big picture stuff. My view is that these decisions should be made a community and then once an agreement has been met, added to our documentation for all to see. My hopes is this ticket, will be one of those discussions. Now you might believe Discourse is a better method of discussion such issues and could replace the wiki. If that's the case, I'd want to know more these features, because I've not see it used in that way. I'm open to suggestions.

So if I could understand what in particular you want to talk about, I could understand your position better.

4. Discourse is for non-technical and non-business communication

So when I said, I wanted to understand what discussion and ideas you wanted to talk about, this is the point I was trying to get an answer to. I personally believe we don't want to create two places for techincal/business discussions. So my question is: what do we need to discuss that can't be done in the above channels, such that we need a Discourse forum. I'll follow up this post with the pros of using Discourse because I do see a need for it in the future. Let me know what you think.

• Finally,

I want to end by repeating my stance on the Discord topic. I think adding a Discourse-like tool for our community is a great idea. And as we scale, we'll definitely need to do so. But the current mission for the community is to get all the projects under it to work together. And therefore splitting up the conversation future seems counter-intuitive. Once this goal is met, then I think we should definitely pick this up and I hope your offer to set one up for us will still stand.

[VikashKothary]

So that above were a few comments to understand why @sandroden you think we need Discourse. Now this is my view.

Discourse is amazing for communication with Users. Users in this case are people who use the product/service without having a hand in developing the service.

My view is that currently everyone in the Glitter chat is a developer. They help make the project better even if they don't contribute code themselves. They ask questions, log bugs, try out new patches, etc.

The struggle is comparing our community with the Anki forum is that there are already a number of products/services that are live: Anki Desktop, AnkiWeb, AnkiDroid, and their iOS app to name a few. We're not currently there.

My view is that once we've got our first stable release, Discourse would be an amazing addition to the AnkiCommunity to allow them to support their users. Support is also considered an external method of communication between the different users of the product/service and I think that's where it shines.

I see a future where users will help each other use our tools and get the most out of them without our help. Which is where all these amazing Discourse features will be invaluable.

I think you see it too, based on your introduction, you're already looking for users for your Wikidattica SRS project. You see the power of Anki-like technology. And we'd love to help support that. But I don't think we're at the place to support non-developers yet (which is why I think GitHub Issues is the best place for support right now). That being said, if you create a ticket about some of your goals with Wikidattica, I'm sure we can align with the AnkiCommunity.

What do you think? Let me know.

[sandroden]

Single entry point

As a person that didn't know anyting about this group until 2/3 weeks ago I can assure you that it's very difficult to gather all the info even to understand if the group is doing something interesting, what they're doing why they have two concurrent servers, how professional they are (that's why I read 4 month of gitter). Not everybody has this dedication and we could just miss people that get disoriented. The wiki will be one step but it says just a (small) part of what the group is.

It's just question of getting a place where you understand what's going on in a glimpse. Discussions spread out in many issues is not practical at all. you don't even have a single page where you see all at once.
I asked questions that simply got unanswered and forgot just because other staff stacked over it.
I pointed out many other features that I really miss here:

• index page of the preminent/latest discussion
• search thought all discussions
• notifications (not very handy to go and "watch" any sigle repo)
• not anything is an issue
• configurable menu
• bookmarks (you like a discussion, you bookmark it - sure you can do that with your browser... it simply is not the same)

Wiki

A wiki is just a way of collaborate to get a document. The result can be formal or informal, you can decide to have both or just one. As an example I can post a collection of useful links and leave it open for others to add some and if at the end we find it generally interesting for the project we decide to promote it to the official Wiki.

Not all is an issue

some technical discussion are not issues in my opinion. There is a typical lower barrier in placing a question that may become more important but may just be answered very rapidly. I would not want to discuss it in the chat as it may get forgotten. I personally prefer to keep issues for bugs that must be solved and carry on discussion in a way more practical forum thread: what's the downside of this? Never repeat things ( I see we all do that when switching a thread to an issue).
I decided I liked this group for the position on how the code should be and stay open-source, that discussion is deemed to be buried under many other (it was 12 of august). I wanted to link it for a friend that collaborates with me on Wikidattica but there is no way.
Presentation of people (as I did) is not to be done in an issue, will rapidly be lost but it's a pity. Other people may desire to know in the future where I come from (to be so fussy... *;-)
An open bug is something non resolved, that needs more work. If I open an issue on what I believe will be nice-to-have for Wikidattica that should not be "closed". I don't see many groups using issues for threads in fact.

Target

I don't believe Discourse is for users. Django community has used a mailing list for 15+ years and now they switched to Discourse. The topics determine if the target is a developer or a final user. When in the future we'll want to address those users we'll just add a category for them, but I see it pretty far away.

Timing

Why not now? Why do we need to scale first. At that point we'll have lost all the founding discussions...
And wasted a lot of time clicking on all the open tags to follow the many issues-non-issues

[VikashKothary]

I've reordered your points in the order that they resonated with me. The top points will be the most effective ways convincing me currently.

Single Entry Point

I completely agree with this list of issues and I feel like I share a lot if not all these issues. Normally when I see this problem, I would introduce a project management tool. Which is an option but comes with it's own pros/cons. I've never seen a forum used for this purpose, so can you explain further. 90% of notifications are from Github so does Discourse come with an integration?

Target

Most the users in the Django Discourse will use use Django to develop websites. A smaller subset will contribute to the actual project. Currently, I want to focus on the people who will contribute the projects, until the first stable release.

Timing

The time period I'm talking about is a very short one. The way I see it, I want to present a clear goal. Right now, we want to minimise the duplication between the projects so that we're all aligned to the same goal. I see the duplication of the discussions between Discourse and Github as against our current goals. It's not a great argument because it's a philosophical one but I hope you understand where I'm coming from. This is related to the next point.

Not an issue

So if you can help me understand the unique use case Discourse meets outside of Github, it would really help. I really like your suggestion that "Issues are for bugs", "Discourse is for Feature Requests". So if we can riff on that a little bit. The reason I like keeping them together (although can be persuaded otherwise) is related to the first point. I can then just plug the github issues into a project management tool, prioritise the issues, align them to milestones and have the entire conversation available at the time of development. What's your thoughts on that?

Wiki

Wiki is just the word. This basically solves the same function as Discource as you mentioned here:

post that become wiki (keep history, easy as writing a post with markdown)

The only difference is that I prefer to review and condense the conversation before it's added to the wiki. I think we both agree that traditional wikis have their limitations and it's important to discuss things before they're added it a wiki. I just don't understand the value Discourse has over

Maintenance

The more touch points we have, the more time will go to maintenance. I just want to have our first stable release of our unified API server, before we start taking on more. You mentioned your Django experience so we would love to have your help with that. Once that's complete, I'd be happy to support your developer of a community forum.

I hope this points make sense. You're clearly very passionate about this and it's great to see. Thanks so much.

[VikashKothary]

Also wanted to add that with the new release of "Github Discussions", it would be good to hear your opinion on it. My stance is they're normally worse than their standalone counterparts, but there's a huge benefit of being tied into the system.

[sandroden]

Single Entry Point

I completely agree with this list of issues and I feel like I share a lot if not all these issues. Normally when I see this problem, I would introduce a project management tool. Which is an option but comes with it's own pros/cons. I've never seen a forum used for this purpose, so can you explain further. 90% of notifications are from Github so does Discourse come with an integration?

A project management tool is not a tool to discuss but to schedule. We're not really in the position to schedule anything as we've go no employees. We can discuss, even people that do not contribute code may be able to contribute in discussion, the we wait till some of us do the job. And we typically cannot complain if it takes more time that desired...

I don't want to divert the wiki as a mean to convey the ideas of the group, but then I get the idea of the quality of a group based on what they write and they produce. I want developers to get this easily.

Target

Most the users in the Django Discourse will use use Django to develop websites. A smaller subset will contribute to the actual project. Currently, I want to focus on the people who will contribute the projects, until the first stable release.

go to the django forum you see all categories served, that click on Django internals and that's just for contributors for code of Django. We probably would not need this double level, we would just be served by the section for contributors...

As a developer interested in the internals of Django I can go there and see what is people talking about, what are they working on. Fellow guys report what they did, developers who care about something ask info, suggest ideas that are discussed. When the "thing" gets in shape they're ready to go and open an issue (ticket in their case). This is exactly what I imagine should happen here: a. I come and say how I'm puzzled by the fact that there are two different concurrent sync-server b. someone explain and the explanation is there for the next time (no there no issue as next time the future myself does not know in which project to look for djankiserv or the anki-sync-server?) and this is not an issue.

We decide to talk of the API, this is valid for both servers, why should it stay in one or the other project? It's interesting for font-end developers, so why should we pick a single repo to open a ticket there?

As you said, you want to make a more "philosophical" discussion, why should it be handled in an issue?

Timing

The time period I'm talking about is a very short one. The way I see it, I want to present a clear goal. Right now, we want to minimize the duplication between the projects so that we're all aligned to the same goal. I see the duplication of the discussions between Discourse and Github as against our current goals.

Right now I spend time going from mail to different tab to follow all the discussions. I never have the feeling to have chosen the "right" place.
As Anton stated the very important thing is "what is a ticket should stay in a ticket". I read it as if I'm the maintainer of a project I want to be sure not to forget a contribution or an issue to solve. No doubt about it.

By "timing" I meant: if this is a useful tool for when we get bigger, it's now the time to switch: if we do it late we'll have lost a lot of discussion on the foundation of the project.

Not an issue

So if you can help me understand the unique use case Discourse meets outside of Github, it would really help. I really like your suggestion that "Issues are for bugs", "Discourse is for Feature Requests". So if we can riff on that a little bit. The reason I like keeping them together (although can be persuaded otherwise) is related to the first point. I can then just plug the github issues into a project management tool, prioritise the issues, align them to milestones and have the entire conversation available at the time of development. What's your thoughts on that?

I hope I understood what you say, but I'm not really sure. Hope not to go too far astray... Probably I'm repeating a bit here...
You can keep together if there's a clear position for a discussion (a bug of an addon, a sync of djanki serve that fails) no doubt where it needs to be filed. Don't even go to the forum for this (I wouldn't even add an automatic mail to the forum).
I want to address all the discussion that wouldn't have such a clear position or a discussion that is pertinent to an architectural choice made that is not wrong but you want to have many people think over it (eg: are we sure that schema is good for a future development that....).

One more case. I'd like to do an addon that does this and that, what you think if I start from... do you know other cases...

These discussions do not belong to a repo and deserve a place where they can get a chance to be seen, maybe even a month from now.

All the time I go to Anki Forum I find ideas on topics that were not the original cause of my visit, just as I skim over the titles and I'm attracted by some. If you split all arguments in different repos (that do not have any connections between them) you'll never get this effect.

Wiki

Wiki is just the word. This basically solves the same function as Discource as you mentioned here:

I don't follow you here... this is just a (tiny) part.

post that become wiki (keep history, easy as writing a post with markdown)

this is just a possibility. As an example, I posted some resources on anki for a developer as a help to myself and those that might get in and since my friend Michele is also looking around, I promoted that post to a wiki, so that he ca add some more resources.

This is not "Our Wiki" in the sense of a place that expresses our mission, job, whatever, it's just a handy way to cooperate. I see many situation in which this could be beneficial in this group as well. Then you may decide to make it a formal document if you like.

If we had Dicspourse, we could ad now a post with a poll to test how many people would like to... go to Discourse...

The only difference is that I prefer to review and condense the conversation before it's added to the wiki. I think we both agree that traditional wikis have their limitations and it's important to discuss things before they're added it a wiki. I just don't understand the value Discourse has over

Discourse will just offer tools, the result is not imposed...

Maintenance

The more touch points we have, the more time will go to maintenance.

Do you refer to the maintenance of Discourse itself? It's minimal in the on-premise I have, and I think is almost zero if you go with the service.

I just want to have our first stable release of our unified API server, before we start taking on more. You mentioned your Django experience so we would love to have your help with that. Once that's complete, I'd be happy to support your developer of a community forum.

I'm totally willing to help out on this. But to get to that there's a lot (I bet) to discuss... and there's no clear place. (back to prison = API discussion above w/o passing from the start *:-)

You've just stated something that I have not read elsewhere: the next goal is to have a unified API server. I probably missed it but I really didn't notice (and I'm clearly glad to know). It's clear that any discussion on this it's a general one that has wide interest well beyond the backend developer. It can sparkle ideas for add-on developers that want to port and addon to the web and so on... it may require some investigating on what others need. All these are not necessarily just relevant as issues in a single repo.

almost the end

ok, I thank you so much for reading and bearing with me... I thank you for not getting angry that an unknown guy shows up and wants to dictate how to communicate.

Maybe a mockup would have been more useful than all these words...

[VikashKothary]

So I'm still not convinced that now is the time for this, even through you do make some valuable points. That being said, I've been convinced by your passion on this topic.

Like I mentioned there are clear benefits to using Discourse which will be valuable in the long run. So I'm happy for you to set up. Here are the actions as I see them:

• Could your setup a Discourse instance for AnkiCommunity
• Once that's done, can you add myself, @kuklinistvan and @AntonOfTheWoods as moderators.
• Finally, can we add a link to all the repo READMEs. A shield would also be nice.

I also ask you to keep a few things in mind:

• please try and limited the concurrent discussions. We've got limited resources, and our most knowledgeable members are also who've been supporting the development of the projects. I don't want the discussions to eat into their development time.
• please try and minimise complexity of the forum e.g. with minimal tags/sections. I want to minimise silos at our current stage of development (which was the biggest selling point for your proposal).
• please try and focus around our unification efforts. Cool features are nice but a strong foundation is more important right now. I think this is a great first discussion.

And I hope that you understand where I'm coming from. I'm sure Discourse will be good for communication but the main goal is supporting development. We have many mission-critical issues that have not been implemented due to our limited resources and I would prefer to be able to focus on that. So if you could follow your gut with this, while keeping my thoughts in mind, I have faith this will be positive for the community as a whole.

Sound good?

[sandroden]

I'm definitely pleased by this proposal and I'll do m best to respect these reasonable requirements.
I'll start applying for a free instance. The only clarification I ask: what do you mean by "silos"?

*:-)

[sandroden]

In the form to apply for a free instance thay request a project site and a code site. While the code is clearly the main github container, would the wiki -in the current state- be a reasonable presentation? or I just put the hitter as a prove of the discussions that attest a community is here?

[sandroden]

Ok the forum is here: https://ankicommunity.discourse.group/
Announce given also on gitter.

[VikashKothary]

I know this is closed, but I'll wanted to reply to your question. Silos are a business term for different parts of the business (or project in this case) that can operate independently.

Anki Sync Server and Djankiserv are completed independent projects which could continue to develop separately. But then we will see some features be implemented in one while others in another. This would be detrimental to the vision however, as they both solve the same business problem (this is arguable but is my opinion).

My goal is to keep the conversation unified until we have a clear single API server, with a superset of the features from both servers.