#1

Recently, two threads on norns development and norns on the rPI were both closed
with the comment… " we’ve decided that this thread " … blah blah.

ok, I thought this was heavy handed, but so be it…

( remember, I put some effort into some of these posts to help other community members… and took care not to duplicate information , as was alleged in the ‘close topic post’)

now… I find Im yet again subject to moderation again today!

earlier someone asked about running norns on a desktop/laptop… (in approach norms , as no tech topics left i guess)
I replied I had it running, and gave some very brief details , certainly nothing that could be accused of being redundancy etc

next time, I come back to lines , I see my (and his) posts have been moved to the closed ‘Norns on Raspberry PI’ topic (despite it having nothing to do with the raspberry pi), so basically ‘dumped’ where they can no longer be continued…

I don’t get it… is this type of discussion now forbidden?

I get you don’t want it mixed in with general users posts, but you have locked the only technical posts there were.

and, no I don’t think GitHub issues are a suitable place for all discussions (especially since very few people are likely to go to GitHub) - or is that the idea, to hide away these things away?

I have to say I’m confused…

I thought lines was a place for open discussion, with pretty light moderation.
yet suddenly norns posts are having heavy moderation, with what should be discussed, where , and how…

8 Likes
#2

Just speaking as a user of this forum, what I would like to see in terms of technical discussion, specifically as it relates to Norns and running it on other things (rpi, linux boxes, VMs, etc.) is a place I can point people to that basically walks through the steps of how to do that.

Threads are a hard place for that because they are flat and mix troubleshooting specific issues info with generally applicable info and it just becomes a lot to parse (and it’s not clear what is the right things to follow and what is trial and error).

I think a .md file or a wiki or (something not a thread) would help to be able to get the data in a more follawable format?

6 Likes
#3

So mine was one of the posts that was moved.

It got moved to the Raspberry Pi thread:

Just for the record, it wasn’t really asking about getting it running on a Raspberry Pi, but more from the point of trying to get a development environment running on my desktop. This relates to my personal dev style, and for me wanting to ensure that it’s something fun for me to do.

Really all I was looking for was someone to point me at the right place to discuss it, as it’s not entirely straightforward given that there are multiple GitHub repos where it could be discussed.

I do understand why the previous threads got to be way too much (they got to be too much for me to keep up with), it felt like some of the discussions on them would have been better suited to IRC/Slack/etc or PMs.

Sometimes I think that as wonderful as Discourse is, the all threads on “latest” style makes it harder to have public discussions without having the ‘public’ all turn up.

It also feels like the ‘move your discussion to GitHub’ is more about the inadequacies of this platform, than about the suitability of GitHub issues.

3 Likes
#4

sure, I think we would all love a document that guides us thru the process…

but many times, people don’t have time to prepare them, my quick guide on the rPI thread, was what I had time to do at the time - is it better to post nothing?
(and I don’t have time to field lots of PMs asking the same/similar questions)

also sometimes such documents come about due to open discussions being held, and the issues being posted (so it becomes a bit of a collation exercise)

yes, that’s a good point…

but are you saying that these topics/discussions are less relevant than others on lines… there are many topics I don’t read on lines, but it doesn’t mean I think they should be moderated away.

I agree, mixing end-user and tech posts is not a good idea, but then why close the posts where these discussion can be held.

(for the record, this topic about running on norns on a VM ive seen at least 3 times, so there is some ‘public interest’… and anyway, often posts might spark interest from others.)

GitHub is dreadful for this kind of discussion, excluding developers, no-one knows about it, let alone knows what issues are , or how to use… and frankly, ‘raising an issue’ does not feel anything like creating a topic for open discussion.
(e.g. how do you ‘close’ a GitHub issue if its a discussion)

I also get the redundancy ‘argument’,
but again, look back at my posts, some of the questions I asked, resulted in GitHub issues against norns being opened. this would not have happened without open discussion. (e.g. see my questions on event thread blocking, or global namespace)

as I said, I’m kind of bewildered…

I just don’t get it, I’m involved in quite a few open source projects, and Ive never felt this negativity (esp. with the original dev team) that I’m getting with norns.

and yes, this is stopping me (as an open source developer) contributing ideas back to norns.
go look at some of the changes on my norns push2 fork, and you will see there are some interesting (general) things I’ve had to address… but I frankly don’t feel comfortable raising/discussing them here or GitHub, because of how things are being handled.

… and this disappoints me, for anyone that has seen me around on other projects, they will know I like to share/contribute, and I’d hope to do the same for Norns, but that’s seeming unlikely at the moment.

btw: I asked @tehn, even before first posting, if he wanted ‘open source’ type discussions of norns to be held here on lines (as I was sensitive to norns hardware being sold), and he said yes.
(later he said, he might come up with a name to differentiate platform from hardware, but that hasn’t appeared yet)

17 Likes
#5

hi @TheTechnobear,

first off, i want to say that i appreciate your evident enthusiasm and skill. i would love to have more contributions from you to the norns code. i really mean this.

i didn’t close the threads or move the posts in question. but i have moved your posts before and i have tried to respond to many of them, so maybe i’m part of the “negativity” you feel. since you’ve made this a public complaint, i’ll make a public response.

in general, i think the threads in question have been pretty noisy and hard to filter for useful information. i think pull requests and wiki pages are the best form of contribution, followed by tickets, and long posts on forums the least useful. i would really like to see some of the technical posts on lines undergo better self-editing - be split into focused questions and placed in the venue where they will be maximally useful with minimal time investment from others.

we all have fulltime jobs (or greater than fulltime) and work on norns when we can. it would be a lot more efficient for us if technical and dev-facing questions were raised on github.

the examples you raise are pertinent to my points:

i believe it would be nice if you made a page on the GH wiki so that the information is persistent and searchable. this doesn’t seem like it would take much more time for you, and would save time for everyone else. (and let me be clear: i’m just as guilty of doing this at times - delivering the information but skipping the legwork to maximize its utility.)

event thread blocking

very true. i read your post on lines, considered it to have some high-quality points, as well as some things i didn’t think were so crucial to discuss. i replied to all of them here on lines, and opened an issue on GH. this took time. you could just as easily opened the issue yourself.

global namespace

actually, there were already related issues on github, like this dated april 28, with much technical discussion already attached (and links to current PRs, no less): https://github.com/monome/norns/issues/258. so this is a perfect example of why, for me its better to take very technical questions and issues to GH. i don’t check lines every day. i mute a lot of categories. i don’t get lines notifications in email. with GH i can be much more responsive.

so…

i guess we have to “agree to disagree” on that one. i think it’s far better to use GH for direct discussion of the codebase.

‘raising an issue’ does not feel anything like creating a topic for open discussion.
(e.g. how do you ‘close’ a GitHub issue if its a discussion)

it’s quite common to use issues as discussion threads, closed or not.

but regardless of your feelings about github: by doing it your way, disregarding my preferences, combining many highly technical questions and crtiticisms in single posts on arbitrary topics, you are forcing me to spend a lot more time and effort on these questions and criticisms; in effect, you are saying that your time is more valuable than mine.

if you would make a PR with the changes you consider relevant, that would make it easy for us to check them out. i really respect your opinions and will take it seriously. but just saying “go look, you will see interesting changes…” seems unlikely to be productive - we need a little more guidance to consider codebase integrations at that level.

this wasn’t my decision. but, i think “norns on rpi” is an okay thread - not great, because the kind of information it generates needs to be collected and edited. nobody was doing that - it’s unfair to expect monome employees or the volunteers working on norns hardware to do that. and there was a lot of redundancy happening.

but “norns:development” is a terrible thread. it can go all over the place and is almost designed to be redunant with the other systems we have. i just can’t see a good reason for not having development-centric discussions in GH, where the code lives, and where we can more easily integrate issues into milestones, know who is working on what, connect PRs, reference lines of code, &c &c.

i dreaded seeing new activity on this thread - which is bad, since i wrote a lot of the norns C code.

in general, i think the moderation moves are trying to encourage exercising a little more editing of your own material, and putting very good information where it can be found, instead of assuming that someone else will do it.

i hope you can take these responses of mine in the spirit of collaboration as they are intended, and as a call for more effective and mutually beneficial exchange in the future. i am really sorry that you feel that the response is hostile - we really want the discussion to continue, but the format here was just not functioning very well and was really taking a lot of time out of our limited coding hours.

so, in regard to this specific question - there is a thread for norns on desktop. unfortunately it is locked. why is it locked? because the thread author requested it. why did they request it? i am not sure, but the statement was “technobear has us taken care of.” and i assume that is because the “norns on rpi” thread had become about “norns on whatever.”

anyways, i agree that it is strange to move active discussion to a locked thread. maybe it was even a mistake to lock those threads, but if so it’s one i can completely understand and sympathize with.

maybe we can treat this interval of thread-locking as a chance to catch up, reorganize and reconsider.

[addendum] @ht73’s post below echos my feelings exactly - and i think accurately describes the motivations for the mod actions. i agree it would be good to have some sort of place for more informal and general development help / discussion / spitballing. it became pretty evident that one thread on discourse is not good for this. i would prefer to see a norns:development category with specific questions in it. walkthroughs should be moved to wiki or readme files. pointing out errors, proposing fixes / features, &c, should be done on tickets. but i am open to opinions on improvements.

in the past, there was a monome IRC channel. i think that might be a good direction - a place to ask for help, but not expected to be a persistent repository of information.

17 Likes
#6

I don’t see it as negativity, rather a worry that important details can be lost in threads with thousands of messages with lots of technical jargon in a format that is not really searchable. It seems the mods are just trying to find a more helpful format so that the discussions may continue.

This doesn’t affect current participants as much as newcomers. Can you imagine someone, with no prior knowledge, starting from the very beginning? That will be lots of folks in six months.

That being said, there seems not any more to be a place to discuss more general development issues, which does seem to be a gap in the current approach.

10 Likes
#7

People will go where the action is. At first, that was on lines. But IMO it should probably be on the GitHub issue tracker. After all, the GitHub page is a natural first port of call for any potential contributor to an open source project.

An issue tracker can be a great place to have technical discussions, with general “problem statement” issues spawning smaller “action item” issues. GitHub allows the cross-referencing of issues, commits, pull requests, and wiki pages. I think the norns development process would do well to take full advantage of these features.

2 Likes
#8

I’ll jump in with @sam and @TheTechnobear, speaking as a developer I enjoyed following those threads with my morning coffee and was pretty bummed when I found them closed today.

In my experience, those (EDIT: informal) threads fuel developers’ enthusiasm for non-profit, unpaid, open-source hardware/software projects by keeping discussion moving freely and applying a vague level of commitment to the participants (EDIT:) without the overhead of process for something I’m simply tinkering with.

It sounds like feelings were indirectly being hurt, but I’m not sure it’s anybody’s responsibility to look at these threads beyond moderators who are looking for code-of-conduct related bad things.

Anywho, glad we can have a conversation about this!

5 Likes
#9

as a non developer, but heavy user, i would like to say that @TheTechnobear’s contributions in the organelle world have been amazing and life changing, seriously, and that it would be sad beyond sadness to not have him active in this community, and that reading what he has written makes total sense, and that i have used too many commas in the making of this sentence.
i also want to express respect for @zebra as a developer in this case, and thank you for your work. i bought norns the second i could, and have greatly enjoyed it, even though it has a ways to go before it is perfect. seeing people try to make just about ANYTHING for it or this community makes me happy, and i hope that no one here gets too salty. because i love you all. (and i hang out with @murray in real life so obv him too)…
<3

7 Likes
#10

Since norns was released I am happy to say that there have been contributions to maiden from five other community members. Nearly all of the discussion around those contributions took place on GitHub (with a little bit of DM on lines).

Personally when I’m pressed for time I will almost always focus on looking at open pull requests on GitHub over answering questions here for two reasons. The first is that someone has already invested time in trying to improve things to the benefit of others and I want to honor their time investment. The second is that I believe I can provide more value to the community as a whole by reviewing and testing changes. I do generally check lines as well but I will be honest and say that I have a hard time engaging in any meaningful way with the longer threads where the topic wanders and the discussion repeats itself when new voices enter.

I recognize that there is value in having a place to discuss the different topics people are interested in, the ones I believe I’ve heard voiced are:

  • development environment(s) / workflow
  • running matron, crone, and maiden on alternate platforms (different base peripherals/cpu arch/os)
  • extending matron to support new controllers / integration with hardware

Regardless of where those discussions take place I do think the (continued) output of it should probably be captured as wiki pages on GitHub. If these discussions did ultimately take place here on lines would it be reasonable to have the individual who starts the thread shepherd conversation and ensure the information made it into wiki pages?

I’d also like to suggest we change the title of this thread to something less provocative.

10 Likes
#11

I would very much like a place to discuss dev environments. Personally I would like that place to be here on lines because:

  • GitHub issues aren’t very nice to for discussions compared to Discourse (notifications, discoverability)
  • It’s more welcoming to new coders (speaking from experience, I’ve answered a few topics about Teletype development here)
  • (more personally) A better sense of community here (I’m a stay at home dad, it’s nice to have discussions amongst a group of people with interests that I don’t get a chance to elsewhere in my life).

If the topic does end up here, perhaps adding “(unsupported)” as a prefix might be a way to avoid a feeling of obligation to participate from anyone, e.g. “(unsupported) Setting up a Norns development environment”.

The info does need to go somewhere, either wiki or a Markdown file in the repo, I think I managed to do that with the Eurorack modules on the libavr32 GitHub page:

(with help from @scanner_darkly).

But before then we need to figure out what information goes into such a document.

5 Likes
#12

Ive changed the title as requested, to something that hopefully is more positive and help move the heart of the conversation forward.

I felt the proactive title was warranted by the provocative moderation … given how little lines is usually moderated - anyway, lets move on

Id like to thank everyone for their considered responses and thoughts on this topic,
I appreciate the opportunity to discuss this further.

generally @zebra I agree with everything in your post, and where we diverge I think is often a preference or opinion, and of course sometime just ‘goals’

I’l not nit-pick on the details, just perhaps elaborate ideas based on one part…

I certainly don’t value my time over others , nor force anyone to spend any time doing anything.
so whilst I appreciate your replies, but I do not expect them, we all have limited time, and lots to do.

Ive a lot of respect for Norns, its code base, and what has been achieved, so I don’t think Ive (intentionally) criticised - my intention has been to try to frame questions to gain understanding, often of intent/direction behind the code.

but, I know the feeling well, others coming along saying ‘why is it like this or that?’,
it perhaps sounds critical (esp. when lots of questions) - but often, it comes down to they have different goals, where they want to go, or were not privy to previous discussions.

(from bitter experience, Ive got this wrong on several occasions, and Ive come across overly defensive, which really harms the spirit - my comment about the push2 fork, was not that I expected anyone to check it, rather to highlight the consequences, of my feeling uncomfortable discussing things here)

so, whilst I can read the code and see what is implemented (and perhaps design ideas), what I cannot see is what others have ‘planned’ in their minds for the future - their direction , thats where i like discussion.

sure, in a perfect world, there would be technical, architectural documentation, roadmaps, GitHub issues, comments in the code that help this - but few projects have any, let alone all of these, as few of us have time to do devote to this - so its never something I expect. (of course, not to say we cannot aspire to this )

this is where open discussion is vital…
its rarely a black n’ white situation, and its thru discussion we start gaining an understanding, and ultimately a respect for others viewpoints, goals, ambitions (even if we might not agree with them) and also a collective feeling of where the projects going.

I dont really have anything against GitHub, nor Github issues ( I use both),

but it feels weird for rolling discussions, which I guess i believe is needed to build up a development ‘community’ spirit.

often topics here on lines, are not really meant to be read from top to bottom, these are more discussions in the moment - the ‘Approaching Norns’ topic has nearly 2K replies, I doubt anyone will read from top to bottom - its a rolling discussion.

I respect the issue with redundancy, and have suffered with this on other projects, its a pain,
fwiw, my approach (which could be wrong) is to try to give elaborate replies (as you have) , and when similar questions are asked, to provide a link back to that answer (or GitHub/documentation or whatever)
I suspect GitHub issue/discourse, will make little difference to that - you’ll still get dupes, and still just have to link to previous response.

there is a positive side, if you have discussions in the open, over time Ive found that others start to reply to these, (esp. if you ‘give space’) - this lessens the burden on the initial developers.
(I’ll admit , Ive struggled with this at times)

I think separating development topics (be it norns or other products) into a separate category is a good idea (and one i suggested to mods before) , and if you feel like its not relevant to most lines users , then like the ‘trade’ category, it could be unlisted.

GitHub issue vs here (in development category)

thats a tough one, to say one way or another,
technically theres no difference really, so its going to come down to the role you attach to a forum, and GitHub issues.

so here can only be my personal viewpoint,

  • I like development discussions to be, to some extent, along side user discussions
    I think often they are related, so to have in one place makes for easier searching.
    also breaking into development and user communities can have some negative consequences.
    (of course, this has to be balanced , against ‘noise’)

  • I view GitHub issues, as more about actions, a to do list.
    mixing, general discussion for me muddies the waters.

  • Visibility/Usability
    In a perfect world, users would add bugs and feature requests to GitHub issues, but Ive found on most projects this doesn’t happen. Users are reluctant to do this, whereas they are very happy to discuss/post on forums. (why is this? we can all have theories…)
    but my point is, there always seems to be a divide created… do we want to do this on discussions as well?

But thats only my viewpoint, of course, others are completely valid - and i totally get, that some times its nice to just be focused on development, and so GitHub, and so bring it there might be great for you.
(Q. if you start having general discussions in GitHub, might that mean your dev focused is lost, because things keep popping up there?)

However, this topic stems more from the fact this move was done without discussion, and then ‘enforced’ with moderation. even the ‘closing topic’ post, felt like it dis-credited contributions made in those topics, framing the discussion as an inconvenience/redundant.

4 Likes
#13

I have nothing to do with norns development (other than being an interested observer) but wanted to chime in with some experiences of how to manage this clash and balance between technical discussion and documentation.

In the indiewebcamp community (now indieweb.org) we developed a discussion and documentation culture born out of collective decades of frustration with mailing lists and web forums (which for the most part are all the worst bits of a mailing list, put on the web) consisting of

  • an IRC channel (mirrored to a slack channel), later split out into multiple channels once there was clear divisions between different sorts of discussion. Browsable, enhanced IRC logs available on the website; and
  • a wiki with a bunch of templates and shortcuts set up to make common tasks easy.

Through enthusiastic community moderation, we developed a culture of “discuss things on IRC, document conclusions or open questions immediately on the wiki”, helped along by an IRC bot which posted wiki edits in the IRC, and even partially automated creation of wiki pages. I found this to be an excellent balance between ephemeral discussion and constantly evolving but always canonical documentation. Github issues were reserved for specific technical and UI issues with specific bits of software (the IW community consists of many separate projects).

This approach requires good tools, committed moderation and wiki gardening in order to really shine, but in my experience the results are worth it. No idea if the people involved in norns development would want to do this, but perhaps it can be an interesting example of how to deal with these sorts of problems.

9 Likes
#14

I’ve said it before, but it bears repeating. Mod actions should be accompanied by explicit communication. It is far too easy to misinterpret any implied communication when that explicit communication is lacking. If you are going to move, split, merge, lock, delete or alter somebody else’s post, it is merely polite to explain why.

17 Likes
#15

i understand your concern, fully agree, and the mods are all on edge about this issue. i certainly announced this change when taking a mod action. and now we’re having a discussion about that decision, which is good.

most of my thinking has been already stated, especially by @zebra and @ngwese.

but i’d like to honor the fact that @sam absolutely revolutionized the teletype code and is a model citizen for open source projects— and code talk was mostly done here on the forum (using git issues as well).

the TT development saga has some lessons, however. at some point there was a massive push to enact a bunch of categories and tagging and labeling conventions… it all failed fundamentally. instead we just have massive per-version threads, and this basically works. the reason this works is because each version is shepherded by the passion of really a single developer. @sam did the first, others followed, @scanner_darkly is leading the charge now. each release has had a limited set of fundamental feature adds/changes. there were never more than a few people contributing at once, mostly because the toolchain and embedded knowledge often required.

norns is very different. there are a lot of contributors. there are a lot of different use cases. there are a lot of inter-working components. norns is an incredibly collaborative endeavor.

so i agree, we need a place where development can be publicly discussed. i think @barnaby’s suggestion is excellent. re there any other ideas?

17 Likes
#16

I think that norns is new for monome and itself as a hardware device, but not new in the context of open-source development. As far as other projects go with forums/mailing-list and a collaborating group of developers: JACK, SuperCollider, the Linux kernel (, etc.

My concern is information was halted on this Norns-specific topic because someone or someones determined from a development perspective that there was “important” information being shared there that wasn’t being recorded in the “right” place and took an action on the community rather than simply using the topic as a resource, recording the “important” information as its discussion grew naturally.

If it’s hard for folks to draw the line, maybe “norns development” discussion should be moved to a mailing list or other forum.

2 Likes
#17

Well, fwiw I think you and @tehn are both right. Norns is not new in the context of open-source development, but few if any of the people working on norns built the Linux kernel, so we (well, probably not me specifically) cannot help but reinvent the wheel here trying to find what works for this group of people.

Since I’ve stuck my head in a conversation I don’t have any connection to, maybe I’ll say a few more things.

  • Moderation on lines is not passive—my requests for topic moves in an attempt to keep, say, the W/ firmware thread on topic were all resolved in minutes.

I’ve read it top to bottom, for what it’s worth. That doesn’t have to be a norm, but I will say for something more related to coding it’s pretty daunting imagining wading through the “noise” of conversation months later looking for the signal—even though in the moment the conversation was a very important factor for reasons @TheTechnoBear and others highlighted! It took much longer for me to find my feet on the Teletype doc enhancements, for instance, because of this.

Anyway, carry on, all <3

5 Likes
#18

I had similar difficulty following teletype enhancements and for that reason I’ve chosen to “watch” (in discourse parlance) the norns tag, meaning I get a notification for every norns post. I have no regrets about doing this but having done so I can clearly see that it’s not for everyone. Huge time sink (that I happen to enjoy in spite of its impracticality).

I understand the concern about splitting the discussion between “developers” and “users” between two platforms, but I also completely understand the desire for more focused development discussions in the interest of productivity and time management. Unfortunately there doesn’t appear to be a lot of middle ground here.

At work we have this phrase that nobody really enjoys but that we have all learned to appreciate the utility of. The phrase is “disagree and commit”. It means you won’t be happy with every decision, but once the decision is made, you’ll commit to adapting to it and carrying it out to the best of your ability. Such notions may have less applicability to volunteer projects, but it may be worthwhile to consider regardless.

3 Likes
#19

I think it’s pretty relevant—“disagree and commit” seems like my feelings about pandoc exactly :joy:

2 Likes
#20

a needed discussion. it’s a bit unfortunate it got emotional before we got here but i’m hoping we can move past that and use the opportunity to come up with a better approach (i will say that communicating mod changes would probably address a lot of concerns about moderation - i don’t know how feasible it would be, and i wouldn’t want to add to mods workload, but a simple notification would really go a long way).

i don’t mind using github for dev discussions, but i think it’s much better suited for things that are somewhat defined already, or something related to code (in which case you really do want to have it close to code). it’s less suitable for general discussions, for reasons already mentioned. i don’t think discourse is a good substitute either, but it’s the only thing we have at this point. it works better as @tehn mentioned when it’s driven by one person. but looking at various teletype feature discussions, those threads have lots of great info/ideas, but it’s buried in super long threads.

i think the approach @barnaby described makes a lot of sense. we really need a wiki or something similar, and a mechanism to link to threads, so that we could discuss here but accumulate ideas or info elsewhere where it’s easier to find.

on a related note, i’ve noticed there’s been general moderation approach where topics get merged into existing topics. it makes total sense when it’s the same question, but feels like lately it’s being applied to topics that are related but not necessarily the same. is there a benefit of having similarly grouped questions all in one huge thread? it doesn’t really improve searchability (actually, having separate topics would probably make it easier to search), and i doubt anybody searches for info just by browsing topics.

and what’s more concerning is when this happens it breaks notifications, and if a post i was mentioned in, for instance, gets merged into a topic i haven’t read i have no way of finding it, as the notifications disappear, and the email notifications links to “topic not found”. are there some settings in discourse that would improve this?

a side note, i find it strange that in 2018 we still don’t have good mechanisms for something like this. are there any implementations for dev specific discussions that would have some built in tooling for what we’re trying to do? it’s funny we have versioning for code, but we don’t apply the same model for discussions. imagine being able to branch discussions off the main thread, and then when an idea or an approach emerges, merging it back to the main discussion.

12 Likes