I just want to express some appreciation to @cmcavoy for taking on a difficult task (even if I am grumpy about silent changes). Apologies for adding a bit of friction, but I think it’ll be helpful if we can understand the method at work.
It was me! Sorry for the confusion @Leverkusen and everyone else.
I approached @tehn and the Teletype volunteer developers with an offer to help organize things. We had a couple of different approaches but decided that organizing threads around specific features was the best way to keep things clear. I had some free time on Friday afternoon so I figured I’d give it a shot as the 2.1 thread was starting to accumulate some new feature talk. I didn’t give anyone a heads up that I was going to spend the afternoon fiddling around, just went for it. I wrote folks DM’s when I moved their stuff into new threads, I also saw messages in the thread that said something about @cmcavoy moving something, but now I’m guessing that’s either something only I can see, or a moderator view?
Yeah, I hear you for sure. Would really like to hear from others about how they’d feel most comfortable being a part of the development discussion. In no particular order, here’s the goals of any organizational changes from my perspective,
Make it easy for the the community to keep track of new features without constant monitoring and involvement in the threads.
Make it easy for the core development team to see which features have consensus from the community (and oversight approval from @tehn or whomever he designates).
Encourage new contributors to see ways they could get involved with development, either through writing code, writing documentation or participating in feature design through discussion.
Keep the momentum up for the current core developers, they’re prolific - would hate to see any changes here discourage them.
Keep the support work of releasing new software - specifically around documentation - easy to maintain.
Discourse (the software that this forum is built on) has some tools for organizing threads, but to really keep things clean (moving stuff around as an example) takes a pretty hefty amount of involvement. Friday afternoon shows that - I spent almost all my time after lunch just watching threads and moving posts when I saw themes that could be grouped.
That level of involvement would be very hard to maintain, plus it was confusing for the post authors. There’s also no guarantee that I (or other moderators) can really organize the content competently. What if a post has multiple topics in it? In short - there’s not a perfect tool in Discourse to keep this all neat and tidy, despite my love of well organized meta-data. The fact is - it’s a bazaar, not a cathedral, the solution to our organizational issues won’t be an engineering feat, it’ll be a community one.
Again, sorry for the confusion. I have time to give and am thrilled to be a part of this community, many thanks to @tehn for open sourcing his work and to @sam@scanner_darkly@sliderule and others for continuing to build us really amazing features. I’d like to help make their jobs easier and help enable others that would like to be involved.
No problem - I really appreciate the ongoing dedication to improve and develop the monome environment by you, @sam, @scanner_darkly, @sliderule, @tehn and many others. Also it is great to see this happening on the background of a brought discussion under the participation of the manufacturer, developers and users and I understand that this does need some form of organization - I remember how the multiple threads mixing support requests, feature requests, bug reports and purchase announcements driven by thrilled anticipation when Ansible was new were confounding the exchange.
As far as I remember @tehn suggested a new category DEVELOPMENT somewhere and this might be a good idea to keep track of the threads and their development.
I am not sure if splitting threads and moving posts is such a good idea though. I think it confuses the flow of the discussion by tearing references apart and forcing them in somewhere else without always adding much to the actual discussion apart from somehow touching the same topic.
How about trusting the community and its individuals to organize them selves with some gentle help?
It’s a good idea to start a new thread when a new feature set evolves in one of the existing threads to split the discussion and keep threads focused. In case the discussion already got substantial it also might be good to split the thread and give it a new start/header in the OP. But in most cases I think just starting a new thread and posting a link in the original thread as an invitation to move that part of the discussion over is a good way to keep the process focussed and easy to follow.
Everyone could then decide how to go on. Posts with multiple topics can stay as and where they have been posted and if there was something substantial regarding the new topic that is still relevant in the new thread one could post it there in a way that fits into the actual course.
I’m not involved in the monome dev side at all, so not comments on that.
but I do moderate and help on a couple of other discourse forums, so have a couple of thoughts / suggestions:
sub categories, I find them really useful, especially on forums, that have different products/purposes. they are really well done on discourse.
(monone and more general seems a natural split in lines, and possibly modular)
I’ve never had issues with users having posts split or moved… (splitting, I usually add a mod note, to say why), moving I only comment if its a new category, to encourage use of new ‘structure’
new categories, I introduce in ‘meta’, and make sure they have a sticky post explain what its for. naming only goes so far.
encourage regular users to reorganise (discourse by default allows this), moving posts is just ‘housekeeping’ , its not moderation (unless you move into a 'private category)… regulars will know what the categories are for, which some less frequent users may not.
(perhaps this is just my view, perhaps a general meta discussion on the difference (or lack of?) between moderation and housekeeping, might be useful?)
Just as in the situation with washing dishes in a big shared house, sustainability requires everyone to do their own housekeeping. And that means everyone needs a somewhat shared understanding of what it means to have a clean house.
When the kiddos are young, the parents have to do a lot more direction around housekeeping, but as the family ages, more of the family is able to pitch in without prompting.
sorry, just a post from a moderator… you can mark it with a ‘staff colour’ if you have many moderators but I don’t usually bother for this… seems a bit heavy handed (but perhaps that is due to how/when i use staff coloured posts)
but I do like to prefix it with something like ‘Mod Note: post moved due to …’, just so users know Ive got my mod hat on at that moment, and why I’m moving.
as I mentioned this is for splitting topics (unnecessary for moving whole topics, imho) where users go off-topic, which can sometimes be ‘sensitive’, even then I try to point out that this is again, just really housekeeping… often i highlight its done so that ‘future users’ searching will not have to wade thru rambling posts to get the answers they seek.
(obviously more appropriate/important for a site more focused on support of a product)
can be tough at times, being a moderator, hats off to those here at lines doing a great job
Feedback would be great. Post it there, or here…either way works for me.
Yeah, you’re both right, although Development doesn’t need to be limited to monome projects but in practice will probably be mostly monome or monome-alternate firmwares. The intent is to have a category that supports the development of these tools…which means a few housekeeping strategies to keep things focused without crushing the creativity.
it is a bit difficult to have to hunt through teletype- and monome-related threads across multiple categories. can the teletype stuff be kept in monome, or better yet, a teletype subcategory just for these endeavors?
also not a fan of crossposting the same thread to more than one category, or crossposting individual posts to multiple threads (ex: the algorithmic post series). crossposting generates a lot of spurious search results and noise, and it’s difficult to keep all those duplicates updated with the same info. there are now four places to discuss software/hardware topics: monome, equipment, dev, and tech, and i see some degree of overlap across all of them.
does the discourse search engine take into account parentheses? if not, maybe there’s no need for the (special) formatting title requirement. what about tags (ex: llllllll) for those topics instead of (prefixes), or are those reserved for top-level highlights? tags might help sort out those topics that touch on multiple categories.
you mentioned subcats and development, and that got me thinking: what about making development a subcategory? instead of top-level, make it a subcategory one level down from an existing top-level category. maybe even apply this approach to existing TLCs:
When I first reached out to @tehn, I wrote up a pretty detailed document to help manage the flow of ideas through lines to github and then into a release. I based it on what I’d seen work at mix of open source and closed source projects. He and a group of the TT devs rightly pointed out that the process was heavy on engineering and would bog things down, also most likely discourage the lines community from participating in discussion. I’m hesitant to speak for that group, but my interpretation of that discussion is to keep things simple and only add additional process when it’s necessary.
My first reaction to the push for simplicity was that it really needed more stuff. I had a hard time coming around to the idea of not using tags, but the more time I spend actively engaged in the process, the more I agree with @tehn (at least my interpretation of @tehn-isms). We could add additional layers of organization to the discussions, but I’d prefer to see how the straight split between Development, Monome and Tech categories goes before we add additional organization layers.
@ioflow / @zebra you each have way more experience supporting this community and working on the monome open source projects respectively, so I’m more than ok with deferring to your opinions, but I thought a bit of context (we started very complicated and then backed off to this current plan) would help.