#29

default is now not to unpin.

@simonvanderveldt i hear what you’re saying and agree that discovery is important. i’ll think on it.

2 Likes
#30

i’m inclined to say the same but can see benefits of both structures, because there are different kinds of users, some of whom might actually be saying “i only want to use lines to look at posts about firmware development.” and we shouldn’t discount the benefits of simplicity. (e.g. any chosen structure is basically arbitrary and will have issues, so maybe flatter is just better.) if we want to support either structure than the answer is tags and not cats.

right now the development category is almost entirely “(Teletype)” posts which is a little absurd.
to take an example of what’s missing (imho), a quick search for aleph posts will reveal that almost all of them involve “development” questions sooner or later (usually sooner,) which is only natural since there is a tiny userbase for the device, and by nature a blurry line between support/studies/dev.
most aleph posts are in the ‘Monome’ category because they are old; that’s not great if the cat is intended for offical support questions.
many threads could be split; ‘ALEPH user STUDY GROUP’ is, despite its name, a mega-thread with many developer discussions and important user-facing stuff like links to the skektek build products. (and now that it has organically become that, i wonder if its really beneficial to split it up.)

so in short i just don’t know how far you wanna go with applying retroactive structure to stuff on the forum from 2015-2016. it would represent a lot of work. without that work any proposed cat/subcat structure seems only half functional to me.

i’d also be wary of using Development for discussion of patching in pd/supercollider/max. not because they are second-class tools or something, jsut that there are few if any lines users actually working on pd/sc sources or contributing to those codebases (sc community has a well-enfvorced and pragmatic line between sc-users and sc-dev), and while there are are a few projects in those environments that really act like “open source” (versioned releases, multiple contributors), for the most part they hermetically created and most discussion will be of a support / user feedback nature.

and just quickly to echo tehn, to me the idea of collecting something in a subcat (e.g. teletype) isn’t about giving it some official stamp of a approval, but should just apply when there is a critical mass in terms of the number of threads/posters, and it starts to make sense for someone following those threads to be able to click a button instead of entering a search term, and for people not following them to not have them taking over the feed by default.

2 Likes
#31

Just want to mention that each of us experiences this forum differently. I read nearly every post, and that means I rely much less on tags/categories to find things of interest. I’m guessing most of the folks doing moderation are “regulars” who may not see the site the same way a more occasional visitor would. Additional navigation support is helpful for less frequent visitors.

3 Likes
#32

Good points! Agreed with all of this :slight_smile:

How hard is it to try something out using discourse? Like for example trying out tags to determine if it works/helps?

#33

ok. i could reconsider the use of tags. i certainly would prefer that to subcats.

re: the mega threads that have left their original purpose-- i’d almost suggest closing them rather than splitting them up. people can start new threads leaving off from a post at any point in a long thread, so it seems good not to hack up old old data.

agreed re: max/pd patches in dev. single-author applications/etc don’t need to be in dev-- but they can certainly be discussed in other cats.

1 Like
#34

Here’s my draft of tag-organization from a PM discussion with the devs. I don’t think it’s right anymore, but it might spark some ideas,

Tags

These tags are grouped as teletype only tags. If the teletype tag isn’t included, these tags won’t be available. Tags can be edited once they’re created, so elements of the tags will change over time. Tags are meant to organize content in a matrix rather than a hierarchy. Posts will most likely have more than one tag.

/ denotes tags that commonly go together, but are separate tags. [things in brackets] mean that things inside the brackets are variable depending on the information being tagged. [things|separated|by|bars] mean that the tag should be one of the words inside the brackets, so [released|inprogress|onhold] means that the tag should be released, inprogress or onhold.

  • teletype / [op|pre] / [command]-[github-issue]-[released|inprogress|onhold]
    • discussion threads that mention commands. The tag can be as simple as op or contain a tag for the command described in the post, r to tag an op command called R. Once the command is added to Github issues for implementation, the tag can be edited to include new information.
  • teletype / tt-[description]-[active|archived]
    • general tag to collect discussion of a broader topic that hasn’t yet resulted in a command or language suggestion. While the prefix tt- is redundant with the teletype tag, the prefix gives the tag some extra heft as an ‘official’ discussion topic.
  • teletype / monome-approved
    • tag that denotes a feature has been vetted and approved for inclusion in the monome TT firmware implementation of the TT language. Does not mean the feature is scheduled for development, or even added to Github issues. This tag is a good place to start if you’re a developer looking for a feature to add.
  • teletype / alt
    • this tag means that the discussed features, while interesting, won’t be included in the monome TT firmware and have yet to find a willing implementor as an alternative firmware.
  • teletype / alt-[alternative firmware name] /
    • tag to denote development discussions for alternative versions of the TT firmware.
  • teletype / release-[candidate|beta|production]-[github release tag, PR or shorthand name]
    • optional tag to collect discussions that relate to a monome TT firmware release.
  • teletype / bug-[github issue id]
    • tag to flag something as a bug. When the bug becomes a github issue, the issue ID can be added for clarity.

Organizing Threads

When multiple ideas emerge from a single thread, the moderators will make their best effort to split ideas into their own threads. While it’s difficult to predict what a discussion will produce, when possible community members are encouraged to keep one topic per thread.

When posts are moved into new threads, or when a thread gains enough traction, moderators may add an index ‘top post’ and change the title to clarify status of the discussion. Thread titles will closely mirror tagging structure,

  • New command threads will be formatted,
    • TT-[op|pre]-[command]-monome-approved-[candidate|beta|production] [additional description]
  • Release status threads will be formatted
    • TT-[monome|alt]-release-[release tag]-[released|inprogress|onhold] [additional description]

Top posts in reorganized threads will link to Github issues, pull requests or releases when possible. Though top post index content will vary according to the purpose of the thread, index authors are encouraged to link to related tags and make use of Markdown tables and formatting for clarity. As index post patterns emerge, templates will be added to this Wiki.

A gif about how I feel right now

I like tags. I like tags a lot.

#35

i’m going to sort of stand by my earlier appraisal that this tag proposition is suited for a much bigger project with many more contributors. it’d be overkill for our needs here.

how about we simply tag the project, ie “teletype”, “aleph” as a sorting method in the Dev cat?

6 Likes
#36

:+1:

Selfish question :stuck_out_tongue: Can you hide/block tags you’re not interested in?

Because development is effectively teletype right now and at the moment I have no use for that info, but am interested in the other info posted in the development category

#37

Discourse does not appear to have a way to exclude tags in searches. You can mute tags, which would remove them from notifications and the Unread tab. That might help you.

#38

Oh yes, agreed. I don’t think my original proposal makes sense anymore.

I’d like to suggest adding a version tag so we could pull up posts that are related to a release easily. At most, a post could have two tags, teletype and teletype-2.2 as examples.

That gif though. It’s a good gif.

#39

i like the idea of using tags since this is a solution to being able to choose only one category, and tagging multiple things means we don’t have to choose between hardware/app, for instance, we could simply have something tagged as “ansible, kria” or “whitewhale, kria” or just “kria”.

being able to search for tags would be really helpful, actually, especially if it’s possible to search for more than one tag a a time. i agree seeing tags would clatter the main page though, is there a way to not show tags there? maybe just show them when you are viewing by category? and i’m not sure having “(Teletype)” in thread names is all that helpful, it doesn’t really help with filtering so it just adds a visual distraction.

#40

Here’s a Discourse forum that uses tags. I don’t think it looks cluttered, personally. YMMV.

#41

i’m sorry to be asking questions about discourse, but i just don’t have time to look this stuff up myself.

is there a way for the moderators to define a fixed set of tags that then users can choose from?

what i typically hate about tags is maintenance, ie TT vs tt vs teletype vs Teletype

#42

You can set a trust level for new tag creation.

#43

slightly different styling though, the font for tags there is grey. also i have a feeling we will have more cases with multiple tags, but this is just a guess, of course.

#44

Yeah, the styling is very much under the control of site administrators.

Here’s a wildly different looking Discourse site.
https://forum.bela.io/

#45

was checking what settings are available for tags and looks like you can subscribe based on tags too - neat!

on a related note, i’m not seeing “Automatically unpin topics when I reach the bottom” option under my profile / interface menu - am i looking in a wrong place?

#46

It’s gone for me too. Because there’s a default now, I’m guessing it’s been removed as a choice. Not what I would have expected.

Agreed. I played around a bit with tags here, the tag maintenance page for discourse is pretty powerful. I get the impression the discourse developers share your feelings.

The piece that I like about tags is the url filtering, https://meta.discourse.org/tags/c/dev/translations/pr-welcome is a pretty url IMO. It’ll make it easy for us to link to slices of content that cut across multiple threads.

Agreed. I’m happy to start editing titles once we’ve all agreed on moving in the tag direction.

3 Likes
#47

I quiet like this as an example. Some basic categories per device and then some tags to easily identify some high level differences between the topics. This could relatively easily be matched to lines I guess (categories like teletype, aleph, grid, maybe software and hardware and tags like development and support)

2 Likes
#48

I’m going to disagree here. If I can’t hide all topics tagged ‘Teletype’ then I certainly want to know that a thread is a teletype thread at the top-level so I don’t waste my time clicking into it. From my perspective, the primary purpose of categorization is to be able to customize what content you see – the default view is everything so it makes sense to be able to cut pieces away from that, so you’re only seeing the interesting-to-you content.

I have the Trade category hidden personally, and I can certainly see someone wanting to hide Teletype. There’s so many other things to read / discuss here!