Request: Collaborator forum #1911
Comments
chrisdickinson
changed the title
|
I am +1 on this. I think that is something that would greatly benefit the collaborators as well as the community. I think this will be beneficial to the community as well. I do really like Discourse too! |
|
In stackoverflow's python chat room, we, room owners are using Trello and it worked out well for us. |
mscdex
added
the
meta
|
+1 <bikeshedding> |
|
@pentode , that's weird to see the words "community" and "discount" in one sentence. Does it support pure mailing list mode the way discourse does? |
|
@rlidwka Heh. No, it doesn't support traditional mailing lists AFAIK. |
|
I'm sorry - but why privacy? Why would we want to move discussion between collaborators out of the open into a private channel where it's not in the open? I definitely agree about the code base - a wiki could do wonders to preserve knowledge and a discourse could be nice. |
So people don't report regular issues on it, probably. I don't think it needs to be limited to strictly GH collaborators though. |
|
@Fishrock123 I'm not worried about "getting in" but thanks for having my back. I'm worried about the implications of not having this sort of not having discussion in the open. I see a pretty big distinction between limiting who can post* (to reduce noise) and limiting who can view the discussion . From what I understand the request here is to limit who can view the discussion as well which doesn't sound like a very good idea. Why would we want (as an organisation) to endorse not doing things in the open?
|
|
@benjamingr ah yes, I didn't think about that. It would be good to keep it public, but read-only-ish imo. The only thing we need privacy for is for security issues, which we already sort of have now for those on the tsc / upcoming security team. (I think there's going to be a security team?) |
|
Privacy where it is essential for security sounds entirely reasonable to me. All I'm asking is that the parts where it's not a security risk would be publicly readable - just like in es-discuss. By the way, I've been reading es-discuss for a while now and I've never seen a spam issue there - there is the occasional "user who didn't do the required reading before sending a message" and every once in a while a user who posts a link to their blog but it's mostly really on topic. |
|
I agree that it should be publicly viewable (minus security) |
|
Yes – the forum would be publicly viewable but only writable by collaborators – that was the problem that I was running into with running this as a GitHub repo: to get the desired ACL system would have required a private repo. There might be a case for private topics at some point, maybe, but I don't think we need private topics right off the bat, though. Email is a good enough venue for discussions about sensitive topics (security issues, collaborator nomination, TSC nomination, etc.) for the time being. There may also be a case for a public forum (or support forum) – but that's down the line and doesn't directly address our needs at present: a place for collaborators to discuss the work of collaboration. |
|
I think it should be a regular mailing list + something like esdiscuss.org to back it up. Forum is not a good idea because it adds yet another place for people to keep the track of. |
|
I don't like GitHub for discussion, and agree that a forum or mailing list would be better. I personally think forums are better suited for discussion than mailing lists but do not feel too strongly about it. |
|
@rlidwka We've gone down the dev mailing list route before, and it hasn't proven particularly sustainable so I was hesitant to broach it again. What would you say the other benefits of a mailing list are over a forum, in this case? I'm not super sold on the "one place to track everything" argument, because even with GitHub I'm still tracking 3-4 different repositories plus email, and doing so in a mix between the command line, the website, and my email. |
|
@chrisdickinson , there are 3 websites I visit every day. It's github, ycombinator and webmail (with a few mailing lists attached to it). What are the chances that the forum will become the fourth one? Well it depends on how active the forum will be, but I don't think they are very high. And if it will be another mailing list, I'll just subscribe to it and will we able to respond to any messages within a day (because I'm checking email frequently anyway). Another github repository like hapijs/discuss is welcome for the same reason: I'm already watching github notifications, it doesn't require checking new websites once in a while. It doesn't matter what my personal workflow is, but if many people have the same one, forum will easily be forgotten, but mailing list won't as long as it has enough subscribers. |
|
@rlidwka Discourse supports email notifications and digests, as well as reply by email, so you'd likely still be using webmail regardless. |
|
Related openjs-foundation/summit#1 |
|
I'm afraid that adding yet another forum is doomed to failure. If we've found anything over the course of the last year it's that adding another tool that people need to check is only going to pick up a slice of the people we're trying to reach. In the worst case scenario these forums end up staying around indefinitely because that slice of the community stays active but totally silo'd. A private repo actually sounds like a great idea and I'm a bit confused about some of these points.
If this repo is only for collaborators what moderation tools do you expect to need? If we have to moderate active collaborators in a private forum we have some serious issues (which I don't believe we have) and the moderation tools available (locking and remove message) would seem sufficient.
This sounds like we're overthinking this a lot. There's 40 active contributors, what do we need ACLs for?
What is not archivable about Issues? They are even searchable.
Let's assume that you won't be able to get the majority of the participants to check a new website every day, which I think is a fair assumption. With that in mind the topics that are "sticky" are the ones people are actively engaged in, in any forum or tool, because those are the ones with email notifications going out which is how a good percentage of the people involved will use the tool.
I do find that long GitHub comments don't "feel" right. Long initial issue descriptions seem fine but responses don't. However, I can't think of a tool other than mailing lists where long responses are the norm -- and those long responses on the mailing list are also the cause of a lot of disengagement from the list itself. You have to remember that encouraging more words also leads to a decline in readership and additional engagement, tools that keep responses concise and small allow more people to stay engaged. |
|
Of this list, this is the only one I think should be private.
The rest of these all need to be public and must be on GitHub if you expect to actually reach the community.
You can't hide the mechanics of how the project is functioning from the community that is not yet an active collaborator. When you do that you ensure that we don't grow new contributors and that the project remains inaccessible. Using a tool other than GitHub to make these public is nearly the same as hiding them in private since GitHub is how the community at large engage in open source. If you're worried about being flooded by non-collaborator responders or sending too much noise to the main repo you could have a public "stand-up" repo for some of this. |
This forum is just for collaborators, and we can make it as binding as it needs to be. For example, right now, there's no way to reliably get the word out to collaborators about a commit freeze, unless each of them checks every issue at all times. With a forum we can sticky the topic for the duration of the freeze.
Sorry for the wording, there. What I'm trying to convey:
This is not to say that I think we're going to absolutely need moderation, but I would rather not have an unmoderated venue (forum or github repo) be the place where collaborators are expected to discuss issues. Better to have the option to moderate and be able to enforce it than to not have it and need it. Additionally, for folks looking to become collaborators, I'd much rather be able to say "yes this forum where discussion about collaborating happens is subject to the CoC and is moderated" than "we didn't think we'd need the tools when we built the forum." Re: overthinking, I have given this some thought, yes – initially I thought about going with a GitHub repository, but, again:
Private repos don't work because the public can't view them, public repos don't work because the public can comment on them, GitHub team ACLs don't work (AFAIK) because to have write access to the repo basically means one becomes a moderator of that repo's issue tracker.
If we're in a private repo, then we have to build a separate tool to archive them out to make 'em public. It wouldn't be hard but it feels like unnecessary extra effort. If we're in a public repo, we don't have a problem with archiving, but now the general public are able to post.
Those collaborators will still have a subject in their inbox with the title "COMMIT FREEZE." They should be able to check that email thread to see if it's still stickied. If that's not possible, a ten second glance at the forum before pushing commits to the project – which is not an everyday thing for all collaborators – would not be an onerous.
Issues encourage medium to long form as well – the short-form bit was to address the potential of using gitter, slack, or IRC.
Using a tool other than GitHub and failing to message it is the same as hiding it in private. To that point, just because we can't immediately capture 100% of the GitHub audience doesn't mean doing this isn't valuable. Twitter is useful, but isn't GitHub; the website is useful, but isn't GitHub; IRC is useful, but isn't GitHub; TSC meetings (on Google Hangouts and Uberconference) are useful; but aren't GitHub. All these sites are tools that have to be used in concert to make something truly "public." For whatever we choose, I'd be happy to reach the same size audience as the TSC meetings. It doesn't have to be immediate, though, the goal is ultimately to provide this for the collaborators. We get pretty far vongforming GitHub (with apologies to @domenic) to meet our needs, but we should also recognize where we're compromising our community's needs to make using GitHub work. |
How do we expect to convince all the collaborators to check this new tool regularly? And if you do, is this not then another barrier to entry for new contributors that they now have to onboard in to yet another tool. If you just want to get a notice out we can build an email list from the GH team using mailgun.
I'm still not seeing the use case for locking threads so that collaborators can't comment, we don't have so many that this should be a big problem. Also, little known hack, if you lock a ticket right when you create it you effectively have a read-only public ticket that only collaborators can edit.
It sounds like what we really want is a blog with email notifications when a new post is created?
It's not that I don't believe these use cases are real it's that I think you're drastically underestimating the work involved in getting people to integrate another tool in to their workflow when they aren't dedicated to the project full time like you are. We've been getting a lot of new contributors and most of them are nowhere near working on core stuff full time and I doubt they will add another tool in to their workflow for a single project they work on part time. I also don't think this is the right way to approach these problems. First posting that "we need a tool" and then later exposing a few piecemeal use cases isn't a great way to find a product fit or explore ways of accomplishing these goals without a new tool. Sure, you can outline all the features for some ideal tool to tackle a few use cases but the best tool is usually the tool that is "good enough" and is already in use by the people we're trying to reach but it's very hard to have that conversation when we being with "need to new tool" rather than "i need to accomplish these things, let's find a good way to do that." |
Serious agreement. Email is where I check for notifications. If you create a forum I'll have to decide whether it's interesting enough to get emails for every post, or noisy enough that I check it every few days when I'm bored. Looking at the OP's use cases:
This would be good, and is the most compelling use case. But, IRC is usually enough.
Not really a good use of my time
Seems like a job for issues, no?
This never works. Every corporate or project wiki I've dealt with, including Chrome, is outdated and incomplete enough to not be worth consulting in most cases. Documentation belongs in the repo or not at all.
Email me, although I'm not sure sprints are the level of detail I care about.
We're not exactly lacking here. |
|
I would like some kind of forum to ask questions specific to collaborators and not of general interest - such as how to find a PR in the io.js multi build. This isn't worth creating and issue to ask, and the current irc channels seem a bit overwhelmed. #v8 used to be effectively the collaborator conversation repo for node, but there doesn't seem to be a replacement. |
|
OK, let's back up. Sorry that I've been pushing for a specific solution, and arguing as if my mind has already been made up – it's not. To restate the background for why I'm requesting this: We are adding lots of collaborators at this point – both from our initial pool in io.js, the joyent/node collaborators, and the most recent group to be onboarded. The onboarding process helps set the tone for those collaborators, but it's only 30 minutes to an hour long, and can only accomplish so much. After the onboarding, collaborators are pretty much left to their own devices. As a result, we have a lot of different perspectives on what the project should be – what should go in, what shouldn't, about optimizations, about documentation, about a ton of aspects of the process. This materializes on the tracker in the form of arguments on pull requests and issues. While some disagreement is healthy and we have remediation in the form of raising the issue to the TSC, in practice the TSC often opts to punt contentious issues back to the tracker, and debates continue far longer than they should, often ending in "most forceful argument wins." This degree of back-and-forth on the tracker is creating an environment that is not conducive to bringing more people onto the project, as @isaacs noted. It can be especially bad if non-collaborators are caught between two arguing collaborators. We should be able to resolve this by taking these sorts of disagreements to a separate space. Additionally, that separate space would be a good place to indoctrinate new collaborators to the project's modus operandi, and for the existing group of collaborators to be able to interact and start to form a loose consensus about the project's values. Right now the only ways for a collaborator to reliably talk to all of the other collaborators are to either post an issue on the main tracker, or to email all of the other collaborators. Posting issues on the main tracker is not ideal, because not all things a collaborator might want to talk to other collaborators about are issues with a definite end. Due to the open-ended nature of these conversations, they would clutter the tracker, burying other open issues. Emailing other collaborators feels invasive, is more difficult for receiving collaborators to filter, and is inherently private. Not everything we want to talk about with other collaborators is private, so defaulting to private feels bad. The following solutions to the problem have been proposed:
The biggest thing I'm hearing from this thread is that folks don't want to change their workflow. Email and GitHub are the common denominators. The other thing I've seen is that at least a few collaborators would be interested in having a venue for conversations with other collaborators. |
I know this is a perception held by some folks, and it's absolutely something that I'm personally interested in helping address (I think someone else used the term "discussion culture" to describe exactly what's happening in this thread and how it's not conducive to certain types of people getting involved). However, I do want to push back a little on the precise assertion of "most forceful argument wins." and ask for evidence of this actually happening in io.js. I can't think of any instance where this has been how something actually plays out, rather, some contentious issues are resolved by collaborators (and/or TC members) finally stepping up/in to assert that something should not happen. This is exactly how it's supposed to work - if you believe that a change should be made then you need to make a case for it. The natural posture should be for changes not to be made and having an ever-expanding body of people who have the ability to assert their disagreement with a change just increases the onus on the person wanting to make the change needing to make a good case for it. Currently I fail to see how we can decrease the need for discussion while still maintaining the integrity of the system we are building. I know that it's not conducive for people that are intimidated by discussion and for people who don't have time for discussion (I don't have time for a lot of the discussions that happen here any more and that's fine). I'm also interested in reducing barriers and making it more accessible to a more diverse audience but currently I don't see a path to that which doesn't involve a reversion to something resembling a BDFL model where someone is allowed to turn off the discussion for the sake of inclusion. I'd desperately love to be enlightened though as we should always be seeking to improve. And yes, I've just contributed to this culture of discussion by writing something that's so long that only a minority of people will have the time to read--but hey, those people interested in tackling this specific problem will read it and hopefully enter into a meaningful and constructive dialog! |
From my perspective, this has to do with diminishing returns on adding increasing the number of independent actors without solidly building consensus around values between them first. Discussion is good, but the absence of a space for collaborators to build an identity around collaboratorship means that most of the additional time-investment new independent actors bring to the project is going to be spent on disagreements. I'm not saying that we need to stop discussion – or even stop disagreeing – the solution I see is to get more of the collaborators on the same page. The best way to get a large group of people on the same page is to get them to talk to each other, and give them a space where they can build a collective identity in the process. Right now the space for collaborators to talk to each other is focused on the tracker, which is a lightning rod for disagreement, and doesn't allow much wiggle room for forming a collaborator identity. We pull in a lot of different directions at present – small core, big core, no core, deprecate-and-delete on a timeline vs. no timeline, micro-optimizations of JS are key, micro-optimizations are a distraction, all commit messages must be pristine and perfect on every PR, commit messages are mutable and can be fixed up by the committer, etc, etc. For outsiders, it's really hard to jump into contributing because we haven't messaged well what we expect from them. For a lot of this stuff, documentation doesn't suffice, either, it's more a problem of building a culture around the project – it can't be dictated, it's got to be built by the collaborators, and they've got to have a space to do that in. |
Some of this is fundamentally impossible. This doesn't mean we can't listen to each other and legitimately take each other's points of view into consideration. All the points you bring up are legitimate issues, and I think it may be worth putting together a list like this where maintainers can discuss this and come to an agreement. We'll have them documented, but the only developers we'd specifically ask to read it are those who can sign off on a PR. |
|
By "maintainers" I meant TSC. And I hope to never see "commit freeze" mentioned again. First, this is git not SVN. If there were a freeze it'd be to push to a specific branch. Second, why would this ever happen anyway? A branch can be cut easily from any commit. Cut a release branch, make the necessary changes and publish it. |
|
Here's a list of things that happen on Issues and PRs that I know have caused people to contribute less or to refrain from contributing at all.
All of that said, I don't have any great solutions to these problems, but these are real things I've heard are problems from actual people who have considered or attempted to contribute. In fact, in a few cases I've heard people refer to these incidents as "the loudest argument wins" and when I investigated the issue it was actually one of these problems but the contributor, not already being culturally conditioned to the project the way we are, took it to be a place where loud people show up and win by default. We get really good at ignoring certain people and conditions when we're contributing and talking in issues all the time but all of these thing we find annoying but trivial end up being bigger barriers to entry than we realize. It should also be noted that in most of these cases people showing up in these threads are not Collaborators, so a solution involving some kind of greater onboarding or forum or "indoctrination" won't work. |
|
@mikeal you've done an excellent work of outlying three very annoying issues in discussions here. Like you said you don't have any solutions for them. I think you sort of do but that's for another thread. I see two distinct issues here:
I think @chrisdickinson's idea is about solving the former and you're talking about the latter. |
|
Probably my fault for getting us sidetracked. However I still take issue with
and now also
They actually sound to me like intentionally inflammatory comments intended to win an argument themselves! We could do without the mischaracterisation of what really goes on here because this is not a reflection of the very constructive and largely positive processes I see happening. I think what we're actually dealing with is barriers to entry for those who are less inclined to jump in on the deep-end on a process that involves a lot of interaction with a lot of different kinds of people, some nicer and more tactful than others. While I see this as somewhat inevitable in an open model without the heavy authority of an individual or group of individuals willing to throw their weight around and shut down discussion (yuk), I also think we need to do better and find ways to be much more accommodating, understanding and respectful to potential contributors. |
Even if you don't think that this is what is actually happening (and I don't BTW) you have to recognize that things are happening that people are interpreting as this. I do believe that this is a mischaracterization but I don't think it is a malicious one, it's the perception people have and they have some reason for holding that perception that we need to understand if we are to resolve these issues. |
|
Ping @chrisdickinson I think you were planning to do a write-up and close this after nodeconf? :) |
|
@Fishrock123 Yep — unfortunately I'm tied up at the moment so this is on the backburner. I'll close this with a writeup once I get the forum set up (whether that's in a GitHub repo or otherwise!) |
|
@chrisdickinson ... ping ;-) any reason to keep this one open? |
|
Closing due to lack of activity. Can reopen if necessary |
We have a lot of collaborators now, and we're about to get even more via the fifth onboarding, not to mention node's onboarding. This is great!
However, I feel we're getting to the point where a pinch of organization would cure a pound of potential ills. It would be great to have a forum for collaborators:
Essentially, I'd like a place for collaborators – not all of whom are on IRC – to be able to discuss the work of collaboratorship. At first, I was convinced that this should take the form of a private GitHub repository, but after some thought & discussion; I think a forum might be the best venue. The attributes I'd like are:
Right now I'm leaning towards Discourse or phpBB, though I'd be open to other suggestions. Slack and Gitter are not viable solutions for this problem – they solve immediate discourse, and prefer short-form content. I'm looking for something more like es-discuss or es-discourse.
Are there other options to consider? Are folks strongly opposed to adding another place to check for information about the project? Would anyone else be willing to step up and moderate?
The text was updated successfully, but these errors were encountered: