Discussion categories


#7

Yes, but users don’t need to categorize their own questions.


#8

Does discourse support tags so beginner/intermediate/advanced could be tags and searches could include tag values?

rather than

  • Usage
    • Beginner
    • Intermediate
    • Advanced

with those as tags instead

  • Using
  • Types
  • Functions
  • Arrays
  • Modules

or

  • Using
  • Abstract and Concrete Types
  • Functions and Mulitdispatch
  • Vectors, Marices and Arrays
  • Modules and Packages

would help orchestrate the high level ideas and the larger areas of inquiry


#9

Mr original intention was to have quite a flat forum, with one place Development for discussion about the development of the base language and compiler, General/Usage for discussions about how to write Julia code, asking questions, and as a general discussion forum about the Julia ecosystem.

We can also encourage categorisation from users and disallow uncategorised posts. Tags are an alternative way of organising.

What do people think about Domains? I was originally a bit confused about its meaning, maybe Topics or Communities would be appropriate.


#10

I’m not sure about “Communities” since I may want to ask a GPU question regardless of community, no? To me the purpose of having these categories is to allow people to opt in and out of discussions of certain kinds of subject matter.


#11

With the small explanation of what the category means I am happy with the name and the purpose.


#12

Meta - I think “site feedback” is a clearer name. There’s no need (afaik) for abbreviating the category titles, and meta makes me think it is for meta-programming.

Development - I’m not sure I see how Language differs from Internals vs. Library, so I would leave it out. But I would add Packages + Ecosystem and Deployment.

Other categories that don’t appear to be covered but might be useful include announcements, meetups (social, local, or community might be other names for this), and jobs.


Should we have a "META" category?
Should we have a "META" category?
#13

The difference between Internals, Language and Library is pretty clear to me:

  • Internals: stuff that is not visible from Julia at all.
  • Language: stuff that exists in the core language before loading sysimg.
  • Library: all the stuff we define and load when building sysimg.

Language and library affect everyone; Internals should only be visible in terms of performance and memory usage. Maybe there’s no point in distinguishing Language from Library, but there’s a lot of people who don’t care about internals at all.


#14

Hi, the move to discourse has been brought to our attention at BioJulia as possibly replacing our Gitter’s and so on. I’m wondering you think focused groups like BioJulia, JuliaStats, JuliaDocs, JuliaGPU and so on should follow this trend and have their own discourse setups, or whether all of them should simply come here and do everything on julialang.discourse under the domain (btw can we have a Biological Science domain on here pleeeeze? :slight_smile: ).


#15

In my opinion I would like to see the communities coming together in one place, but it is up to the communities to make that decision. Speaking for JuliaGPU we are planning to promote and use https://discourse.julialang.org/c/domain/gpu.

Created the Biological Sciences subcategory :slight_smile:


#16

Thank youuuuuu :smile:.
We’re currently discussing this over at: https://gitter.im/BioJulia/Bio.jl, and it’s been asked is there anything say Gitter can do that discourse can’t right now? I expect Github integration is probably possible…
Oh would you like me to give a bit of BioJulia blurb to put in the “About This Category” for Biological Science?


#17

Discourse is more of a forum, long text discussions (with formatting, code-highlighting, etc…), whereas Gitter is more of a chat-room (ephemeral?). What level of Github integration are you looking for?

If you send me a PM with a blurb I can update the category description.


Visualization in Julia
#18

So I think it’s stuff like mentioning specific PR’s and such.


#19

I think it would be helpful to add a new/announcements channel. A place for package maintainers to announce new packages, new releases etc etc.


#20

I like the general structure and agree that we should add an announcements channel.

I have one question: How should one deal with smaller topical groups? There is a small JuliaGeo community with a github organization maintaining a few Geoscience related packages and a low-traffic mailing list which is mostly used for announcing geo-related packages. Would this deserve its own Geoscience domain or should we create a geo tag and announcements and questions would go to the general list.


#21

I think a Geo subcategory would be good. Basically anything that could have its own mailing list seems like a candidate for a domain subcategory.


#22

I wish there was a way to delegate administration of subcategories, but there doesn’t seem to be. As more people use this system, they’ll automatically gain trust and moderation capabilities though, so I think this will start to resolve itself.


Spanish language community
#23

I’m not sure if you are looking for suggestions in this thread, but maybe a separate “Announcement” forum where people can follow package tagging and news.


#24

Ok, so once a Geo subcategory is created we would transition there, since there were no complaints on the julia-geo mailing list.


#25

Geo domain created: https://discourse.julialang.org/c/domain/geo. Please edit the About Geo page as appropriate – I’ve made it a wiki, which should let people edit it as I understand things, but if that doesn’t work, let me know.


#26

What’s wrong with low traffic categories, as long as they do have some?

Suppose that in the future a not-yet-existing subcategory acquires traffic withing an existing big category. How do we expect to ever make the split reasonable, if discouragement is our criterion? Cause the old big category will still have more traffic than any new one (as is the case with Usage anyway), so that discouragement will always stay in place. Or who will bother discovering and moving the past relevant threads from the chaotic big category to the new subcategory? Therefore we’ll get stuck to the few categories decided early. Is that desirable? Do you have a different positive scenario in mind? Or does current consensus fail the whole concept of categories?

If the subject of a category is worthy to subscribe to, then low traffic is a plus, not a minus!

The only encouragement to use a category is for it to exist. If users end up not categorizing their posts and moderators end up moving many threads all the time, why not give moderators more categories to work with, along with giving users more specialized subscription options?


Machine Learning and Artificial Intelligence
Machine Learning and Artificial Intelligence
Scientific Computing Category