#32

The software development organization I’ve managed for the last 7 years has used the following:

  1. A live text chat environment (with separate “rooms” for specific topics and projects) e.g., Gitter or Slack
  2. A live voice chat environment (with screen sharing and notes tab) e.g., Google Hangouts
  3. A durable wiki for preserving project documents with related narratives e.g., MediaWiki
  4. A ticketing environment (with a vigorously-groomed backlog, release planning and assignments facility) e.g., GitHub or JIRA
  5. A public forum facility (for accepting public feedback and discussing topics with users) e.g., Discourse, UserVoice
  6. An executive-level project planning facility (for showing the ebb and flow of projects at the level of milestones), e.g., Trello

Software development is a team sport that suffers when roles become blurred. This is especially true of open source projects with large communities, something I’ve avoided managing because I value my health.

3 Likes
#33

yeah, I agree, lines its a bit split on its identity…
there are many that want it to be less ‘gear focused’ (see comment on hiding trade category),
yet its backed by a ‘gear manufacturer’, so its walking a difficult line.
(not only norns, aleph seemed similar, as also eurorack at times)
no solution or critique, just recognising its hard, and a balancing act the mods are doing a good job on.

this may be true, though many of us are in different timezones, so not sure how ‘live’ it would be, but certainly the ‘transient’ nature of the discussions perhaps is better suited.

however…
Like some others, Im trying to reduce my social media consumption/footprint , and using yet more platforms - fills me with dread (actually, more likely i just wont signup, as I have to draw a line somewhere :frowning: ).
this makes me wonder, perhaps this is a sub-conscious concern I have with GitHub issues for discussion.
whilst I use it as a repo server - I really don’t want to turn it into another social media platform.
(esp. now its microsoft owned)

but again, these concerns may be limited to me…
and there is an argument for the ‘best tool for the job’, rather than trying to arbitrarily limit social media platforms and forums i interact with.

#34

apologies for my slow response. i’m traveling and internet access has been spotty.

one proposal:

use the (presently underutilized) Development Category which lines users are free to mute.

but i feel this is only effective if we avoid mega-threads.

unfortunately avoiding mega-threads is fundamentally impossible without heavy-handed moderation (because a huge percentage of users will not stay on topic and moderators will get sick of the extra volunteer work to be verbose at letting people know they’re off topic and their message was moved)

but, we can try this, but i’d almost caveat that if by posting in the Dev category we all make our best effort to stay organized and on-topic, and agree to be moderated (this may mean calling for more volunteer moderators).

it’s good also to remember that what we’re discussing here is effective means for collaboration, and i’m grateful that you all are sticking around to discuss the very idea of collaboration. thank you! i’m hoping we can figure something out quickly, so we can get back to programming, and then stop programming sometimes so we can all enjoy the musical utility of the stuff we’ve built together.

13 Likes
#35

I think this is a ‘culture’ / by example thing…

here, creating new threads for specific technical things, or questions, has not been the way its done,
rather things get lumped into broader topics.
(because of lines broad nature)

if you start creating lots of specific threads, like
e.g. (Norns) how do I sync midi clock with norns.

then others will follow, as its seen as a norm

if anything on Axoloti we at times have the opposite issue,
where similar threads get created (as people dont search), so I sometimes combined (if its important)…
I less frequently have to split threads (but thats also pretty easy on discourse)

Ive generally never had too many comments about moving posts around (unlike closing),
people seem to view it as ‘tidying up’ - the only issue (which I think others have mentioned on lines) , is discourse doesn’t really inform the poster of the move very well - so Ive had people thinking its disappeared/been deleted (which they get uppty about … till you point them to it :slight_smile: )

however, axoloti is a product specific forum, so ‘thread explosion’ is no issue
how well that works on lines - not sure…

do you think it been better to make development as ‘opt-in’ rather than ‘opt-out’?
then the new noise, might be less of an issue?

#36

Development has been part of monome culture since day one. Lines has expanded beyond that but I’d be sad to see it become a place where development is no longer seen as an inviting playground.

But I’d love to see more granular threads, more volunteer moderators (raises hand) and if the development category became opt-in, I’d definitely do that (but I hope we can make this action super easy to discover!)

4 Likes
#37

Chipping in my two cents as a follower who is not deeply involved in development:

I really have enjoyed reading through the talk between active developers of the Norns platform. As someone not as well versed in these topics, I’ve found myself using these threads as a way of understanding 1) the development process, 2) the hardware side of things, 3) how these tie together. I’m fine with the discussion moving elsewhere (whatever works best for y’all’s ~process~), but I’m sure I’m not the only one who reads through all of the Norns threads top to bottom, even the development ones, and thoroughly enjoys it.

The developer category seems like a good idea. Hopefully it isn’t muted like the trade category, though.

11 Likes
#38

I think that is what might be what is meant by “opt-in” and it seems unnecessary to me as well.

#39

Ill offer another non dev perspective via an analogy - fun huh?

these threads in a general forum (meaning everything from obscure coding to high range ethical discussions - its the strength of this place IMO) are like a magic eye picture - if you see it right (ie your a dev and or right across the tech be it hardware/software ect), or your a musician (drummer say, like me) you might see nothing but noise. So any contributions from ideas from non techy people are difficult as its so splintered where would you put this info for it to be seen and relevant if you could nut your way to hopefully the right area

Also given Norns isnt even at release it makes it even more confusing to get a grasp of the whole ecosystem…

I dont have an answer to this problem

3 Likes
#40

i love the analogy. i wonder if categories treated as lenses might not help here? (i admit i pay little attention to them myself but maybe with a little discipline they can be part of a partial answer?)

which is just to say, maybe it’s not important to be able to as long as there are ways to not lose the thread of the narratives you care about.

2 Likes
#41

I’d prefer if there was a Norns category, which I could mute if needed (i.e. if it takes too much bandwidth for me) rather than using the Development category for Norns, as I’m really interested in all the Teletype dev threads for example.

1 Like
#42

You can mute the norns tag.

#43

If you need advice on how to maintain or contribute to an open source software project, Karl Fogel’s book “Producing OSS Software” is always a good source. He was part of the Subversion team for a long time, which was maintained by a company - but had a large volunteer contributor community. His advice is mostly geared towards much much larger projects, but it never hurts to page through it when you’re not sure what to try.

Here’s the chapter on forums, where he talks about what goes into the ticket tracker v. what goes into an open discussion forum.

Your mileage may vary.

6 Likes
#44

Some forums have a culture of keeping the first post of a thread updated to reflect the contents of the thread, especially as related to newsworthy things. A hand-curated thread summary, if you will.

I feel that the Discourse feature of wikifying the first post is intended to support this kind of culture. If this policy was “enforced” a bit more here I feel it would go a long way towards solving the signal/noise issues that we have here.

3 Likes
#45

could we relax the preference not to use tags for the development category specifically? we already have 2, norns and teletype. if we want to avoid mega threads it would help navigating multiple topics.

we could still limit it to mod curated tags only. i think something like toolchain, release discussion, feature request, issue, documentation, but could also be more device specific, norns on pi, for instance.

a good start would be for the OPs to turn their original post into a wiki so that others can keep it updated too (say, Ansible Earthsea topic is a good example that would benefit from it as it would give me the opportunity to update the first post with the link to the firmware/documentation).

2 Likes
#46

yeah, just watch out for the wiki post multi-user issue I mentioned above… it can lead to a lot of confusion
(where your sure you updated something, but then come back and find its gone)
… its ok, for fairly static posts, but not if you have a few eager users updating it.

I think the proposal, is only for development related norns posts… other norns posts would remain in monome.

another possibility used on the C&G forum, is to use sub-categories , they are pretty good.
(esp. if you colour code their icons nicely)

2 Likes
#47

Yeah, it would be best if new topics were always started with the implied responsibility of the topic author to curate the original post. Under some special circumstances (original author gone/disinterested/etc) the post could be wikified. But, just to be clear, does Discourse lose the concurrent edits, or just save them as older versions, like most wikis do? If it’s the latter one, I don’t see it as a huge problem. If making a longer edit, just put a notice up top or something.

#48

I was not aware this was a discourse feature. Sounds useful!

#49

yes, let’s be clear what we’re talking about:

development is different than basic use of norns, which includes making your own scripts (studies) and just playing scripts (bug reports, questions, etc). the latter posts should go in the monome thread.

work on the ecosystem itself (matron, maiden, etc) should go in the development category.

i do not think development should be muted by default. i’d suggest that collaborative coding is part of the core principle of lines.

i’m skeptical that we need tags for navigation. a category seems fine. forum posts should be relatively ephemeral, and when they escalate to action, a git issue should be created. the forum is perhaps a good place to pursue an early idea, or point out a design change.

i’m also skeptical that wiki pages in discourse are the best route, unless they’re treated as scratchpads for collaboration which will eventually get committed to READMEs in a repository.

the reason i say this is the more structure imposed, the less likely it’ll be adopted. i believe we should make small incremental changes.

so, the change proposed:

  • use the development category for more atomic norns development issues
7 Likes
#50

It’s pretty basic forum functionality that I feel should be in the hands of end-users. Don’t try to structure it. Tags are “folksonomy” (look it up, it has a history).

1 Like
#51

Well… away I go…

I figure the topic can be moved / re-categorised / closed / burnt once we know what we’re doing.

3 Likes