Reconsider use of talk.commonmark.org

[howardroark]

I think it is a bit painful for the need to divide input between two platforms. It creates a cause for people to be weary about their thoughts and enforces an amount needless policing. When a new contributor comes by and enters feedback into GitHub it is likely to become a lashing rather than taking the information seriously. The strategy should be to utilize issue tagging and assume that any good discussion could eventually lead to a pull request which could close it. Nothing should ever be closed immediately, it should only be marked as discussion and only ever closed when some sort of consensus is reached.

It would be best if "talk.commonmark.org" was a layer on top of the GitHub API that cataloged issues which were tagged as discussion. Any new Topic added to "talk.commonmark.org" would be automatically added to GitHub in a properly tagged state. Depending on the permissions allowed to OAUTH it should be possible. This would allow you to easily put together milestones and start growing a cohesive workflow.

The discussion site should also be enabled with the ranking feature that Reddit and Hacker News use. The patten itself is very well understood. If done properly you could get quite a number of quality open-source projects going under the "CommonMark" name. Why not distill that pattern into something very reusable.

If you wanted to go even crazier you could store all GitHub discussions as JSON objects and ensure that there is a two way syncing between GitHub and the talk.commonmark.org service. You could even work on a JSON schema with the express purpose of defining a discussion. Really work to discover what the best pattern really is by asking the community. This would also allow you to also keep the comments in version control. As users modify things you could ensure that a history is always backed up so that no one can sneak a change in without others being able to alter their arguments to reflect the difference.

Who knows it may stop 70 mile long discussions from occurring if users are more encouraged to just work away on their own unique arguments. To be honest a good deal of any discussion tends to be an oddly passive aggressive song and dance as people just pick apart points of a bigger picture. Kind of like animals at times really... but you always know the strongest wins; Why not just let it be the best argument that wins in each discussion.

I think it could help clear up a considerable number of redundant issues and harness the community in a much better way. If done right it could be a very useful project for any GitHub repo. It could even start to influence the way that GitHub deals with comments in the first place. Or even better, the standard it uses to parse Markdown in the first place.

I am also a bit sad that the code for talk.commonmark.org is not available at https://github.com/commonmark

This is also posted here... http://talk.commonmark.org/t/reconsider-use-of-talk-commonmark-org/610

[Bengt]

Isn't talk.commonmark.org just a heavly debranded disqus?

You can actually like posts by clicking the ♥ under them. Perhaps there is a way to sort responses by likes via an extension.

Compare GitHub's wiki: It is also a means of communication (author(s) to reader) and is backed by Git. One can not work on wikis using issues and pull requests, though. That seems a sound design decision, because it meets the expectations of former wiki users. Disqus works a lot like a bulletin board, or a forum and former users of those systems would be surprised if a forum would suddenly work like an issue tracker.

[vyp]

talk.commonmark uses https://github.com/discourse/discourse.

[howardroark]

I really feel that the talk section has to be fitted with a natural way to ensure that the top arguments are always subject to a constant anonymous vote. This is the only way that you can ensure the direction makes sense for what people really want out of it. The pattern used on Reddit and Hacker News is very universal now, especially in the development community.

It would be really awesome if there was an attempt to distill this pattern into a more universal state that other projects could leverage. Focus on relying on OAUTH services like that of GitHub. It would also be awesome to make the pattern about up/down voting what is essentially JSON objects that can be version controlled. Maybe the AST idea mention model fits in here somewhere? There could certainly be use for a tool that could convert GitHub flavoured markup to a JSON AST (I may be misunderstanding what AST is for). So long as it could incorporate raw text formatting and HTML.

An engine that syncs comments between this format and GitHub's issue log would be such a valuable way to also test out the direction of future open-source project workflows.

[vyp]

Just wanted to note this from http://commonmark.org/ (emphasis mine):

With your help, we plan to announce a finalized 1.0 spec and test suite in the next few months

So perhaps, in anticipation of requests for things not already in the core, they decided to use talk.commonmark as a place to harbour such requests/discussion so that github issues could focus on the more immediate goal?

[howardroark]

I mean that could be the reason and I do understand it. I don't think that is a good enough reason to separate the content though. You can easily solve that problem with Milestones.

The bottom line is that people are used to the GitHub interface and it is not ideal to detour people with an entirely different experience.

It would be most optimal to design a plan to maintain the use of the accepted interface while allowing ambitious people to experiment with a new one.

[hkdobrev]

👍 Discourse is great, but not helpful in this case.

When GitHub's Atom launched it used Discourse. Atom used to be closed source and Discourse was very helpful to gather feedback and discussions.

However when Atom was open-sourced bug reports, feedback and pull requests moved to GitHub. The conversation got separated. I think in the end GitHub wins when the product is targeted towards developers and is in active development.

I realize Discourse is from @coding-horror and he is part of CommonMark, but his Discourse is just not helpful in this scenario.

[rlidwka]

Discourse is great, but not helpful in this case.

Same thought here, I usually don't like having to switch to another website to discuss something. And almost all developers are on github anyway.

[BigBlueHat]

Interestingly, the Web was designed (originally) to solve this very problem. If we were posting links + their relationships (rel="reply" or rel="annotation") and sending LINK method requests (ala, HTTP/1.1 "beta"), we'd be building up a Web (crazy...really) of conversation from All The Things.

Barring that awesomeness finally being created, it'd be helpful to have the conversation closest to the code, action, etc.

Integration between Discourse and GitHub issues would also be cool--then folks could talk where they talk. Webhooks is probably the fastest, "done" thing to implement that. Or someone can help me implement LINK methods. ;)

👍 to using GitHub (and Discourse if integration is possible).

[styfle]

I imagine that the "talk" site is for all things CommonMark while this issue tracker is only for the implementation. But I agree with the following statement.

I think in the end GitHub wins when the product is targeted towards developers and is in active development.

[howardroark]

I'm not even a "programmer" and I still love GitHub. I understand programming, but I'd rather just get people who like doing it to make stuff. GitHub is where all my Markdown lives in version control. I love to write and discuss. Projects like prose make that possible, and offer a great example of how easy it is to extend the platform. Using issues to talk about ideas is an extremely common practice.

I think it would be fantastic to extend GitHub via the API and evolve the way that discussions arrange themselves around projects. Be it code or a book, it makes sense. It just needs to be backwards compatible with GitHub in order to capture the whole voice.

Sending people over to another site will always augment the perspective. You end up with only the people who are extra eager. The conversations can end up being self congratulating and drift away from a bigger picture.

There is no evidence in society that just because you make a rule that people will follow it properly. Things need to be natural.

[jcracknell]

I think you will find the issue is that especially in the case of a Markdown specification which superficially seems simple and straightforward, you get a hell of a lot of bikeshedding going on - particularly following the initial announcement.

At some point in future it might make sense to be less restrictive, but not while everyone who has used Markdown a time or two wants their say.

[howardroark]

I love wikipedia links:) To me it sounds like bikeshedding is a good thing! It is a sign that your project has merit and that a large subset of people wish it to succeed. What is and is not trivial is still a huge grey area. If you take the time to sort things, you will get better at it over time while also getting a larger sense of what people are thinking. Creating a secondary host for what is assumed to be trivial information doesn't really solve anything.

I'd also argue that every issue is always at risk of bikeshedding within its own discussion. People should be encouraged to continuously clean up and formalize their initial comment as discussion continues. In fact I'd love it if every discussion was more of a constructive effort to see if the initial thoughts could be better shaped.

I'd argue that in cases like this it starts to separate two groups of people. Those who want to encourage Markdown's direction and those who understand Big O notation. Why shouldn't everyone get their say in one place? I don't see how else you get what people want out of it. If the people who make the things always want to separate themselves from the people who want it... Well how do you get what people want? Or at least understand what it is that they want. It may take a bit of translating or education, but if the goal is for this to normalize and become self-sustaining it seems to be best to keep it all in once place.

[howardroark]

I'm going to close this up. I think I have gone a little off the rails here, as is my nature. Though I do think there is a very good case for leveraging what GitHub is offering.