Request: Collaborator forum #1911

Closed
chrisdickinson opened this Issue Jun 7, 2015 · 37 comments

Comments

Projects
None yet
@chrisdickinson
Contributor

chrisdickinson commented Jun 7, 2015

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:

  • To ask advice on how to deal with issues
  • To run check-in / "stand up" threads on a regular basis to get an idea of where everyone's at
  • To coordinate sprints on issues, labelling, features, etc.
  • To work out disagreements-in-approach in advance
  • To develop, document and retain "communal" knowledge about the codebase
  • Getting the word out about merge freezes, sprints, immediate roadmap, etc.
  • To build more of a community around the project (vs. Node-at-large)

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:

  • Moderation tools
  • ACLs for posting or responding to topics, not necessarily for viewing them
  • Archivable
  • Ability to "sticky" important topics to the topic of the list
  • Preference for medium-to-long-form content

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?

@chrisdickinson chrisdickinson changed the title from Request: Collaborator backchannel to Request: Collaborator forum Jun 7, 2015

@evanlucas

This comment has been minimized.

Show comment
Hide comment
@evanlucas

evanlucas Jun 7, 2015

Member

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!

Member

evanlucas commented Jun 7, 2015

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!

@thefourtheye

This comment has been minimized.

Show comment
Hide comment
@thefourtheye

thefourtheye Jun 7, 2015

Contributor

In stackoverflow's python chat room, we, room owners are using Trello and it worked out well for us.

Contributor

thefourtheye commented Jun 7, 2015

In stackoverflow's python chat room, we, room owners are using Trello and it worked out well for us.

@mscdex mscdex added the meta label Jun 7, 2015

@pentode

This comment has been minimized.

Show comment
Hide comment
@pentode

pentode Jun 7, 2015

+1

<bikeshedding>
Nodebb is certainly worth consideration for this purpose. I'm currently running a pilot with it at work and the teams are finding it useful and have raised very few complaints. The nodebb developer community seems to be quite healthy. They do offer nodebb "as a service", and it wouldn't surprise me if they'd offer a significant discount if they were able to advertise the fact that the nodejs project uses their service.
</bikeshedding>

pentode commented Jun 7, 2015

+1

<bikeshedding>
Nodebb is certainly worth consideration for this purpose. I'm currently running a pilot with it at work and the teams are finding it useful and have raised very few complaints. The nodebb developer community seems to be quite healthy. They do offer nodebb "as a service", and it wouldn't surprise me if they'd offer a significant discount if they were able to advertise the fact that the nodejs project uses their service.
</bikeshedding>

@rlidwka

This comment has been minimized.

Show comment
Hide comment
@rlidwka

rlidwka Jun 7, 2015

Contributor

@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?

Contributor

rlidwka commented Jun 7, 2015

@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?

@pentode

This comment has been minimized.

Show comment
Hide comment
@pentode

pentode Jun 7, 2015

@rlidwka Heh. No, it doesn't support traditional mailing lists AFAIK.

pentode commented Jun 7, 2015

@rlidwka Heh. No, it doesn't support traditional mailing lists AFAIK.

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Jun 7, 2015

Member

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.

Member

benjamingr commented Jun 7, 2015

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.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Jun 7, 2015

Member

I'm sorry - but why privacy?

So people don't report regular issues on it, probably. I don't think it needs to be limited to strictly GH collaborators though.

Member

Fishrock123 commented Jun 7, 2015

I'm sorry - but why privacy?

So people don't report regular issues on it, probably. I don't think it needs to be limited to strictly GH collaborators though.

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Jun 7, 2015

Member

@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?

  • and accepting requests to join and what's being suggested
Member

benjamingr commented Jun 7, 2015

@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?

  • and accepting requests to join and what's being suggested
@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Jun 7, 2015

Member

@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?)

Member

Fishrock123 commented Jun 7, 2015

@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?)

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Jun 7, 2015

Member

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.

Member

benjamingr commented Jun 7, 2015

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.

@evanlucas

This comment has been minimized.

Show comment
Hide comment
@evanlucas

evanlucas Jun 7, 2015

Member

I agree that it should be publicly viewable (minus security)

Member

evanlucas commented Jun 7, 2015

I agree that it should be publicly viewable (minus security)

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Jun 7, 2015

Contributor

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.

Contributor

chrisdickinson commented Jun 7, 2015

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.

@rlidwka

This comment has been minimized.

Show comment
Hide comment
@rlidwka

rlidwka Jun 7, 2015

Contributor

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.

Contributor

rlidwka commented Jun 7, 2015

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.

@monsanto

This comment has been minimized.

Show comment
Hide comment
@monsanto

monsanto Jun 8, 2015

Contributor

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.

Contributor

monsanto commented Jun 8, 2015

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.

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Jun 8, 2015

Contributor

@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.

Contributor

chrisdickinson commented Jun 8, 2015

@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.

@rlidwka

This comment has been minimized.

Show comment
Hide comment
@rlidwka

rlidwka Jun 8, 2015

Contributor

@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.

Contributor

rlidwka commented Jun 8, 2015

@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.

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Jun 8, 2015

Contributor

@rlidwka Discourse supports email notifications and digests, as well as reply by email, so you'd likely still be using webmail regardless.

Contributor

chrisdickinson commented Jun 8, 2015

@rlidwka Discourse supports email notifications and digests, as well as reply by email, so you'd likely still be using webmail regardless.

@mikeal

This comment has been minimized.

Show comment
Hide comment
Member

mikeal commented Jun 8, 2015

Related nodejs/summit#1

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Jun 8, 2015

Member

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.

Moderation tools

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.

ACLs for posting or responding to topics, not necessarily for viewing them

This sounds like we're overthinking this a lot. There's 40 active contributors, what do we need ACLs for?

Archivable

What is not archivable about Issues? They are even searchable.

Ability to "sticky" important topics to the topic of the list

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.

Preference for medium-to-long-form content

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.

Member

mikeal commented Jun 8, 2015

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.

Moderation tools

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.

ACLs for posting or responding to topics, not necessarily for viewing them

This sounds like we're overthinking this a lot. There's 40 active contributors, what do we need ACLs for?

Archivable

What is not archivable about Issues? They are even searchable.

Ability to "sticky" important topics to the topic of the list

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.

Preference for medium-to-long-form content

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Jun 8, 2015

Member

Of this list, this is the only one I think should be private.

  • To ask advice on how to deal with issues

The rest of these all need to be public and must be on GitHub if you expect to actually reach the community.

  • To run check-in / "stand up" threads on a regular basis to get an idea of where everyone's at
  • To coordinate sprints on issues, labelling, features, etc.
  • To work out disagreements-in-approach in advance
  • To develop, document and retain "communal" knowledge about the codebase
  • Getting the word out about merge freezes, sprints, immediate roadmap, etc.
  • To build more of a community around the project (vs. Node-at-large)

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.

Member

mikeal commented Jun 8, 2015

Of this list, this is the only one I think should be private.

  • To ask advice on how to deal with issues

The rest of these all need to be public and must be on GitHub if you expect to actually reach the community.

  • To run check-in / "stand up" threads on a regular basis to get an idea of where everyone's at
  • To coordinate sprints on issues, labelling, features, etc.
  • To work out disagreements-in-approach in advance
  • To develop, document and retain "communal" knowledge about the codebase
  • Getting the word out about merge freezes, sprints, immediate roadmap, etc.
  • To build more of a community around the project (vs. Node-at-large)

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.

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Jun 8, 2015

Contributor

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.

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.

ACLs for posting or responding to topics, not necessarily for viewing them

This sounds like we're overthinking this a lot. There's 40 active contributors, what do we need ACLs for?
[...] the moderation tools available (locking and remove message) would seem sufficient.

Sorry for the wording, there. What I'm trying to convey:

  • if we have a public repo, the general public can view and post.
  • We want the public to be able to view, but not post.
  • We also want moderators to be able to lock threads.
  • Because the collaborators would have write access to the repo, locking threads is effectively impossible.
  • Essentially, everyone with access to the repo for posting issues becomes a moderator.

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:

  • I don't want the public to be able to open issues (or respond to them) there,
  • I don't want backlinks from "forum" comments to issues,
  • I want adequate moderation tools,
  • and I want an effective channel for collaborators to address all other collaborators.

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.

What is not archivable about Issues? They are even searchable.

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.

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.

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.

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.

Issues encourage medium to long form as well – the short-form bit was to address the potential of using gitter, slack, or IRC.

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.

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.

Contributor

chrisdickinson commented Jun 8, 2015

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.

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.

ACLs for posting or responding to topics, not necessarily for viewing them

This sounds like we're overthinking this a lot. There's 40 active contributors, what do we need ACLs for?
[...] the moderation tools available (locking and remove message) would seem sufficient.

Sorry for the wording, there. What I'm trying to convey:

  • if we have a public repo, the general public can view and post.
  • We want the public to be able to view, but not post.
  • We also want moderators to be able to lock threads.
  • Because the collaborators would have write access to the repo, locking threads is effectively impossible.
  • Essentially, everyone with access to the repo for posting issues becomes a moderator.

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:

  • I don't want the public to be able to open issues (or respond to them) there,
  • I don't want backlinks from "forum" comments to issues,
  • I want adequate moderation tools,
  • and I want an effective channel for collaborators to address all other collaborators.

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.

What is not archivable about Issues? They are even searchable.

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.

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.

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.

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.

Issues encourage medium to long form as well – the short-form bit was to address the potential of using gitter, slack, or IRC.

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.

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Jun 9, 2015

Member

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.

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.

We want the public to be able to view, but not post.
We also want moderators to be able to lock threads.

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.

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.

It sounds like what we really want is a blog with email notifications when a new post is created?

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.

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."

Member

mikeal commented Jun 9, 2015

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.

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.

We want the public to be able to view, but not post.
We also want moderators to be able to lock threads.

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.

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.

It sounds like what we really want is a blog with email notifications when a new post is created?

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.

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."

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jun 9, 2015

Member

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.

...
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.

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:

  • To ask advice on how to deal with issues

This would be good, and is the most compelling use case. But, IRC is usually enough.

  • To run check-in / "stand up" threads on a regular basis to get an idea of where everyone's at
  • To coordinate sprints on issues, labelling, features, etc.

Not really a good use of my time

  • To work out disagreements-in-approach in advance

Seems like a job for issues, no?

  • To develop, document and retain "communal" knowledge about the codebase

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.

  • Getting the word out about merge freezes, sprints, immediate roadmap, etc.

Email me, although I'm not sure sprints are the level of detail I care about.

  • To build more of a community around the project (vs. Node-at-large)

We're not exactly lacking here.

Member

domenic commented Jun 9, 2015

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.

...
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.

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:

  • To ask advice on how to deal with issues

This would be good, and is the most compelling use case. But, IRC is usually enough.

  • To run check-in / "stand up" threads on a regular basis to get an idea of where everyone's at
  • To coordinate sprints on issues, labelling, features, etc.

Not really a good use of my time

  • To work out disagreements-in-approach in advance

Seems like a job for issues, no?

  • To develop, document and retain "communal" knowledge about the codebase

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.

  • Getting the word out about merge freezes, sprints, immediate roadmap, etc.

Email me, although I'm not sure sprints are the level of detail I care about.

  • To build more of a community around the project (vs. Node-at-large)

We're not exactly lacking here.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jun 9, 2015

Member

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.

Member

sam-github commented Jun 9, 2015

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.

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Jun 10, 2015

Contributor

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:

  • Create a new GitHub repository.
  • Create a new mailing list.
  • Create a new forum.
  • Use IRC.

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.

Contributor

chrisdickinson commented Jun 10, 2015

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:

  • Create a new GitHub repository.
  • Create a new mailing list.
  • Create a new forum.
  • Use IRC.

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.

@rvagg

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Jun 10, 2015

Member

"most forceful argument wins."

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!

Member

rvagg commented Jun 10, 2015

"most forceful argument wins."

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!

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Jun 10, 2015

Contributor

Currently I fail to see how we can decrease the need for discussion while still maintaining the integrity of the system we are building.

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.

Contributor

chrisdickinson commented Jun 10, 2015

Currently I fail to see how we can decrease the need for discussion while still maintaining the integrity of the system we are building.

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.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Jun 10, 2015

Contributor

the solution I see is to get more of the collaborators on the same page.

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.

Contributor

trevnorris commented Jun 10, 2015

the solution I see is to get more of the collaborators on the same page.

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.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Jun 10, 2015

Contributor

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.

Contributor

trevnorris commented Jun 10, 2015

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Jun 10, 2015

Member

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.

  • Endless bikeshed threads -- we've gotten really good at ignoring and unwatching these but when these are left to go on indefinitely they end up being viewed by most people who newly watch the repo and the conduct in them is never an accurate representation of the rest of the discussion active contributors tend to engage in.
  • Performance adjustments that border on trolling -- yes, some PRs require a very thorough performance review because they are in a hot path but for many simple PRs it doesn't matter. When people show up and suggest a ton of adjustments because of what they've learned through obsessive micro-benchmarking it makes the person who sent the PR feel like never returning. This isn't a matter of "learning" the right way like I've seen happen in many of the C++ PRs, this is obsessive and holds new PRs to a standard most of the code base is not in.
  • Mixed code review and "this should not be in node" discussion -- We have a lot of good discussions about what should or should not be in node, we also have a lot of good code reviews, but when someone sends a PR and gets totally mixed signals about either A) working to make their PR better and B) getting the impression it won't get merged at all, the contributor is confused and frustrated.

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.

Member

mikeal commented Jun 10, 2015

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.

  • Endless bikeshed threads -- we've gotten really good at ignoring and unwatching these but when these are left to go on indefinitely they end up being viewed by most people who newly watch the repo and the conduct in them is never an accurate representation of the rest of the discussion active contributors tend to engage in.
  • Performance adjustments that border on trolling -- yes, some PRs require a very thorough performance review because they are in a hot path but for many simple PRs it doesn't matter. When people show up and suggest a ton of adjustments because of what they've learned through obsessive micro-benchmarking it makes the person who sent the PR feel like never returning. This isn't a matter of "learning" the right way like I've seen happen in many of the C++ PRs, this is obsessive and holds new PRs to a standard most of the code base is not in.
  • Mixed code review and "this should not be in node" discussion -- We have a lot of good discussions about what should or should not be in node, we also have a lot of good code reviews, but when someone sends a PR and gets totally mixed signals about either A) working to make their PR better and B) getting the impression it won't get merged at all, the contributor is confused and frustrated.

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.

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Jun 10, 2015

Member

@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:

  • Organising a knowledge base about working with nodejs (io.js)
  • The way discussions are held in the github issues

I think @chrisdickinson's idea is about solving the former and you're talking about the latter.

Member

benjamingr commented Jun 10, 2015

@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:

  • Organising a knowledge base about working with nodejs (io.js)
  • The way discussions are held in the github issues

I think @chrisdickinson's idea is about solving the former and you're talking about the latter.

@rvagg

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Jun 10, 2015

Member

Probably my fault for getting us sidetracked. However I still take issue with

"most forceful argument wins."

and now also

"the loudest argument wins"

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.

Member

rvagg commented Jun 10, 2015

Probably my fault for getting us sidetracked. However I still take issue with

"most forceful argument wins."

and now also

"the loudest argument wins"

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Jun 10, 2015

Member

However I still take issue with "most forceful argument wins."

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.

Member

mikeal commented Jun 10, 2015

However I still take issue with "most forceful argument wins."

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.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Jun 25, 2015

Member

Ping @chrisdickinson I think you were planning to do a write-up and close this after nodeconf? :)

Member

Fishrock123 commented Jun 25, 2015

Ping @chrisdickinson I think you were planning to do a write-up and close this after nodeconf? :)

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Jun 30, 2015

Contributor

@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!)

Contributor

chrisdickinson commented Jun 30, 2015

@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 chrisdickinson self-assigned this Jun 30, 2015

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 9, 2016

Member

@chrisdickinson ... ping ;-) any reason to keep this one open?

Member

jasnell commented Mar 9, 2016

@chrisdickinson ... ping ;-) any reason to keep this one open?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 22, 2016

Member

Closing due to lack of activity. Can reopen if necessary

Member

jasnell commented Apr 22, 2016

Closing due to lack of activity. Can reopen if necessary

@jasnell jasnell closed this Apr 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment