Require or suggest availability of a discussion forum? #186
Comments
|
A further comment: In general, the criteria do not say much about collaboration tools beyond version control and bug tracker. Discussion forum in many cases is close in importance to those two, but it might be worth thinking what other tools are worth suggesting. |
|
I've thought about discussion forums, which is why some of requirements are worded so generally. It's important that there be a mechanism for discussion that is searchable later... but projects vary greatly on what that mechanism is. In particular, if you say "MUST have a discussion board" a lot of people will presume that you have to have something like a mailing list or BBS software. However, a lot of projects do not have a separate mailing list, but instead depend on other mechanisms for discussion, and those mechanisms seem to work for them. For example, a vast number of GitHub projects exclusively use the conversation mechanisms for issues and pull requests, and it works fine for them. The BadgeApp project does have a mailing list, but even in that case we tend to use the issue tracker (because it organizes the conversation). A lot of projects use IRC and avoid mailing lists; as long as they're recorded somewhere, I don't see why they should be excluded. And of course there are a huge number of websites designed for group conversations; as long as it works for them, it works. I think the one "discussion" requirement that to me is important is that it be able to be searchable later. But mechanisms like IRC can be captured and searched, so as long as the project makes previous information findable later, I don't see the problem. |
|
Yup -- that's what I meant by "discussion forum" (and is why I did not say "mailing list" or some other mechanism-specific term) :-). The criteria don't need to specify what the mechanism is, but just that it have certain properties. Searchability is one; I would add message and/or topic addressability, that is, the ability to specify a particular post or thing said, via a unique URL. And, of course, that this discussion mechanism, whatever it is, not require that any participant run proprietary software on their own machine. Due to browser tab sandboxing, I don't really consider the proprietary Javascript sent clientward by GitHub and similar sites to be proprietary software running on my machine in the same sense that running, say, Skype, would be. But this is a complex question and there are good arguments both ways. If you lean toward the stricter interpretation, then note that allowing GitHub issues as a discussion mechanism effectively means that someone who wants to run only free software would have to interact with issue comments only via email or via some free software that uses the GitHub APIs. I think some people actually do this. In any case, I think it's worth a "SUGGEST" that the discussion forum, whatever kind of software it is, be useable via email. A number of developers have expressed this preference strongly, some going so far as to say that they won't participate in discussions unless they can do so via email, because that way is so much more efficient for them. |
|
I don't think we should require email. A lot of people in the younger crowd despise email and will not use it unless forced to. Tagline: "Email is for grandparents". Requiring something to be usable by email seems reasonable on the surface, but is it? If people normally use IRC, it's not clear that an email interface (even if optional) makes sense. |
|
Sorry, I spoke too soon earlier. I don't actually put real-time chat systems (e.g., IRC) in the same category as message-based, non-real-time systems. They're different things, used for different purposes. For example, some projects have a rule that while a decision may be discussed in IRC, it does not become binding until posted in the official message-based forum -- they may say "mailing list", but the important part of what they mean is really message-based forum -- and 72 hours or whatever have passed with no formal objection in the same forum. There might be followup discussion, in both IRC and the message-based forum, but the point is that the message-based forum is both the official notice-board and the official record. Message-based forums -- the GitHub issue tracker certainly counts as one -- should have some way of subscribing to them, i.e., getting a feed. Email is the most typical way to do that, though one could use other protocols (heck, the GitHub issue tracker has a good API, right?). So I guess my recommendation is to distinguish between real-time chat forums and message-based forums, and for the latter say that they either "SHOULD" or "MUST" be subscribable, with email as one example of how to achieve that property. That way there is a mechanism for the project to have a feed-friendly notice-board that is topically organized and has archives, and that can also serve as an official record if the project ever grows a need for that. |
|
First, here's what I think we agree on:
It's not clear to me that they're always used for different purposes, though. Always is hard to determine, and I'd like the criteria to stay technology-agnostic if reasonable. Someone should be able to use whatever tech they want as long as it meets certain criteria. Our task is to try figure out what those criteria are, and try to only include justifiable constraints.
Sure, but some projects don't work that way. For example, Fedora uses public IRC meetings as their official decision-making mechanism. They run meetings for making decisions synchronously, and then post the discussions as an IRC log. See: https://fedoraproject.org/wiki/Board_public_IRC_meetings. You might also find the Wordpress guidance interesting, e.g.: https://make.wordpress.org/chat/
The projects I'm familiar with generally use async systems like message-based forums like mailing lists and GitHub issue tracker. But should we mandate the use of async / message-based forums? Should we mandate supporting an email link to them? I don't want to over constrain projects. An argument for async systems is that they enable worldwide collaboration. However, the sync systems enable an immediacy that can arguably increase development velocity, and development velocity is vital in today's software development (it's one of the reasons contributor license agreements are a serious problem - they slow things down). So let's try to identify the key criteria for a discussion mechanism. Here's a start, partly based on your earlier email:
It's not clear to me that asynchonicity should be a requirement. Maybe it should. Let's, well, discuss :-). |
|
I think the the badge-able criteria here are the ones you list above, at the end of your comment -- that's a good list. In a sense, what we really want to say is not easily badge-able: "The project should have consciously thought about when to use synchronous (real-time) discussion forums verses when to use asynchronous (message-based) forums, because the former blah blah blah, and the latter blur blur blur." But to evaluate whether a project has considered those questions well requires an in-depth engagement -- it may not be appropriate for the CII Best Practices list. However, from that item you could link to this discussion, or to some comment(s) in it :-), or to a summary you post somewhere. I guess I think it's important that people understand there are important differences between synchronous and asynchronous, whatever the specific technology. I agree the criteria should stay technology-agnostic, but that's a non sequitur here: this isn't really a technology choice, it's a feature choice. IRC vs Slack is a technology choice, but Slack vs Google Groups is a feature choice. Synchronicity doesn't have to be one of the criteria, but the fact of its not being among the criteria doesn't mean that synchronous vs asynchronous is not an important difference, it just means that one way wasn't clearly preferable to the other way in the circumstances for which CII Best Practices offers badges. I think in practice you don't need to mandate asynchronicity because most of the bug trackers out there effectively provide an asynchronous message-based forum anyway. The Fedora Board example doesn't really apply, IMHO. Many Boards do their meetings in real time, but a Board of Directors is a specific kind of thing -- heck, some U.S. states mandate that official, legally-sanctioned Boards must meet using real-time communications mechanisms -- and a Board is usually only tangentially related to the project community that drives day-to-day progress on the project. The WordPress page you pointed to just says that Slack is going to be their official real-time communications mechanism (i.e., as opposed to IRC, though at least Slack does have a mostly-working IRC gateway). The page does imply that this real-time forum is the place for development communications ("Slack communication is used for contributing to the WordPress project, be it code, design, documentation, etc.") and doesn't make it clear whether or not there's also an asynchronous forum -- my guess, though, is that actually their bug tracker is the asynchronous forum, and they just haven't made explicit the fact that in practice that's taking the place of a mailing list. Easy way to test this: if you're a developer or contributor, can you interact only via the bug tracker (no Slack) and yet get the discussion you need in order to eventually make your contribution land? (Guessing the answer is "Yes" but haven't actually tested it.) Anyway, I think your four criteria for discussion forums are excellent. I just hope the criteria don't imply that synchronous and asynchronous discussion forums are essentially the same thing with just a trivial difference in when the responses come in. I think it goes much deeper than that, and that choosing between them is a true feature choice not just a technology choice. |
|
There's no doubt that synchronous and asynchronous are different, but I don't want to constrain projects unless it's clear that one approach is clearly bad or clearly superior. How about this text (please kibitz): The project MUST have one or more mechanisms for discussion (including proposed changes and issues) that are searchable, allow messages and topics to be addressed by URL, enable new people to participate in some of the discussions, and do not require client-side installation of proprietary software. Examples of acceptable mechanisms include GitHub issue and pull request discussions, Bugzilla, Mantis, and Trac. Asynchronous discussion mechanisms (like IRC) are acceptable if they meet these criteria; make sure there is a URL-addressable archiving mechanism. Proprietary Javascript, while discouraged, is permitted. |
|
Well done. That's compact, says what needs to be said, and doesn't over-constrain. |
|
Here's a post noting that both IRC and Bugzilla have weaknesses, but depending on IRC can easily lead to the situation where you thought something was being done.. and it wasn't: http://jefferai.org/2013/03/29/distillation/ |
|
That's an interesting read, for lots of reasons. It does sound like there the really important dynamic was just "overworked volunteers" :-). Can totally see how Bugzilla would not be a good ticket management system for sysadmins, as contrasted with developers, though. (I almost wrote "as opposed to developers", and then thought, hmm, that particular use of the common expression is perhaps too literal for comfort!) |
This part makes sense, though I wasn't sure if "user" meant just users of the project or includes engaged participants like developers, documenters, bug reporters, etc:
In any case, would it be good to say a project "SHOULD" have a discussion forum available for participants to join if they wish? There need be no requirement that the forum be active, or that developers be subscribed, but it seems at least worth suggesting (or "should"ing, either way) that a forum exist so that people who do want to talk have one clearly-designated watering hole to gather around for that purpose. Otherwise, random discussion forums spring up in places not clearly related to the project, and since they're harder to find than they would have been had they been officially approved, needless fracturing of project discussions can result.
The text was updated successfully, but these errors were encountered: