Comments on: Better Developer Communications
As R3 moves toward larger test releases this month,
we've been having various discussions about
how to improve developer communications, but we've yet to find
the perfect solution.
I think part of the problem may be that we've not defined our requirements well enough.
With that in mind, here's a list of requirements from my viewpoint:
| ||Developer audience||It's intended mainly for developers to discuss
topics related to R3, including design, docs, code, bugs, etc.
| ||Low overhead, rapid flow||Meaning we can easily discuss things at a
rapid pace. We've been using AltME for this so far (but it's not the
| ||Web visible||Although the forum system need not be web based, it's
useful if most discussions can be found on the web. (We did this
with AltME in the REBOL3 world, and it works pretty well.)
| ||Threaded||Code development normally focuses on various topics for
short periods of time, until the code is design is decided, the code is
written or the bug is fixed. Thread mechanisms work best for this;
however, they can be inefficient because they require users to jump
around to the different topics to see what's been posted.
| ||Sectioned||Thread topics can be grouped into sections. For example,
threads related to graphics.
| ||Multi-associated||We want to see discussions in the chat area, but
also next to their focus of attention. For instance, a discussion about a
bug report would appear in the chat area, but also in the bug system
| ||Open and scalable||More than just a few dozen developers have access
to the discussion. I'm not talking about technology here, just the
concept that any developer should have quick access. We don't want to
create barriers to developer growth.
| ||Tagable||A way of tagging messages that are key, have future
relevance, or need to be flagged to the attention of someone.
| ||Searchable||We need to be able to search prior messages, with
various control options for dates, tags, etc.
| ||Carl must use it||This is perhaps the most difficult requirement. I do
not like to waste time, and if I feel I'm wasting my time, I stop. I've
been using AltME because it's fast and partitioned. I can quickly scan
the top discussion groups.
So, now that we know what we need, we can find the best solution now,
google groups? it offers emails too :)
only a suggestion.|
Google groups has been suggested by a few people... and I think there are a few REBOL groups from earlier days. (I think the problem was that Google groups were a bit unpolished back then.)
Do you think that they can provide most of the above requirements?
AltMe would be a very good choice if:
- it could work thru proxies
- registration process is better explained
- keeping web visible threads visible as of today
I vote for AltMe if it uses port 80.
Be sure to host it on something that you own and control.
You can then mirror it to google groups if you wish, while continuing to own it.
Is it possible in Altme to "subscribe" to the threads within it?
Say I subscribe to bug fixes.
I'm in a chat room discussing a GUI and a bug gets fixed.
The system notifies me in the chat area i'm in.
The only thing left we'd need is to be able to watch multi chat rooms at once.
If you can get Altme on port 80, I would like to hear about that.|
I vote for a web interface to Altme, with clear and obvious links on the home page of rebol.com, and a no-brainer instant way to sign up and make posts. I love what Sunanda's gotten started - I read it all online, but have never once made a post there. Make it web accessible, and everyone will use it :)|
I think google groups just might meet 5 out of all requirements.
downside is that, in order to use it, we all have to create a google account. : )|
Google groups is pretty much a non intuitive crap ...|
Grant is correct. If there was greater merit in not fully owning and controlling the development process, you would have open-sourced Rebol from the beginning. If externally based access is deemed sufficiently beneficial, then host-and-mirror is the best way to go.
Raising an aspect that I think is quite relevant, another development blog thread has advanced the excellent principle of using the language as our tools, as much as possible ("Dogfood, Wine,..."). Surely a good Rebol program can support a management interface that will handle posting the entries intended for general developer access in an efficient manner.
Nick has the right idea, IMO. Remove the barriers to developer access, as much as possible, directed from a control level managed by the master developers and directors.
Post a Comment:
You can post a comment here. Keep it on-topic.