This is a good thread, but it might be too early to implement a lot of the categories you’re suggesting. By segregating discussions into topics, we may not need as many categories as their are rooms in HipChat. Rooms in HipChat are necessary so that people don’t have to talk over each other. But on discourse it’s fairly each to sort of from topic titles.
Tags will also alleviate a lot of need for categories. We could make tags for all stack packages (afw, means_base, etc) and for DM groups.
Also, to follow up I’ve realized that tags can only be created from the posting interface. This means I’ll need to be vigilant on reading all posts to add tags for each stack package as needed until the tag taxonomy stabilizes.
The point of Meta is not to be a catch-all, but specifically to help govern the site (ask questions about how to use it, request features, report problems… hence ‘Meta’). It looks like a ‘General’ right now because pretty much all our discussion is about the site The Meta description post talks about this. I realized that people may not see that post because it’s not pinned… and I can’t seem to pin it at the moment.
Assuming the RFC passes, will we be actively evangelizing other sectors of LSST to use Discourse? Or just let it spread by osmosis for a while (e.g., through calibration bringing in people from T&S and SE)?
… and if so, will we need a small number of additional categories early on to handle this?
@ktl’s original post semi-implied that categories can be nested. True? It is not that easy to find documentation on this. I found some posts on meta.discourse.org that suggested nesting was possible, but it’s hard to tell what’s authoritative. (Possible warning flag for our own documentation becoming over-reliant on answers in Discourse.)
I think if we start trying to move things like Systems Engineering conversations over here, we’ll have to have a category other than DM for them.
The not-so-happy-with-Discourse feelings in the DESC may end up spilling over to the camera team, I fear.
I want to write a message about a fairly technical topic (DM integration tests with the Camera DAQ software, to be concrete, but it’s just an example of a general issue). There is a small audience of people who should definitely read and think through the issues I’m going to raise. There is nothing actually private about the topic, as far as I can imagine, so I don’t feel the need to use a closed category with a restricted set of users, and - in any event - no suitable closed category exists.
If I were writing this message as an email to just the people I definitely want to read it, I would write a fairly short message that presumes that they know certain details about the system design that I suspect most DM’ers don’t know and don’t need to know. That would also be true (psychologically, for me) if I were posting to a well-defined category like “Infrastructure” or “Commissioning” or “System Interfaces”. I would assume that people following that category had chosen to do so and would recognize the existence of some expectations associated with the category.
In contrast, posting this to “Data Management” feels a bit like getting up in front of a plenary session at the AHM and starting to talk about this; it seems like there’s an implication that I’m addressing everyone, and that I should a) write the post with somewhat more of a didactic opening and b) expect a substantially wider range of feedback.
I don’t feel that the tags that current exist are likely to serve this function. Tags are not visible on the default topic-list screen, and the current set don’t really seem to form a coherent taxonomy.
This is a bit of a psychological obstacle to getting a quick post out and getting on with the rest of the day’s work. It may be argued that in the long run it’ll be good for the project for me to write a clear tutorial explanation of this area, of course, but for today, it was an obstacle to doing what I wanted to do.
So, after that ramble… I think it would be helpful to have a modest number of categories that can accommodate the idea that there are different - self-selected, not enforced - audiences for different topics.
This is really good feedback. I’ve always thought of categories as a tool to eventually control the steam of information, but never realized that the lack of categories might inhibit communication.
The original reasoning behind having so few categories was that
the initial size of the community would be so small that segregating it into specific categories might be premature, and at worst, provide an extra source of friction to getting onto and finding info from the site
we wanted to let the grass fields get trampled, as it were, and build categories/tags around the paths most taken
In fact, Discourse’s tags implementation has the quirk that tags can only be made in association with a post. I can’t go in and pre-populate a coherent taxonomy of tags.
But as you can see, building a coherent set of tags is still a work-in-progress.
Here’s a possible solution that perhaps we can iterate on and ultimately implement:
(Public) Categories are created for specific work domains. These can likely be sub-categories of Data Management (but see below). The social implication is that posts in these categories will only be of interest to people actively working in that domain and those domain experts can go wild. When the domain experts are ready to address the project more generally with information that could impact everyone, then they’ll post to the Data Management parent category.
Tags will be our way of sorting information in Data Management that’s addressed to everyone in the organization. Note that tags go across categories, so tags can be applied in both the subcategories and the Data Management category (as well as Q&A for public participation).
I also think that matters related to the software stack and data products should stay in the general Data Management category since from a user’s (i.e., community astronomer’s) perspective, that’s probably material that will be immediately of interest. Things like the Camera DAQ, while vital, are probably too close to the metal and most astronomers likely won’t want to think about them.
The problem with this model is that there’s no way to view a parent category while also hiding topics in subcategories. Perhaps the more domain-specific categories need to be grouped under a different umbrella category? Call it Working Groups?