Comments on: Tracking REBOL Projects
I've added a few updated comments to the end of this article, based on comments within the group.
I need your help! These days there's far too much going on in the world of REBOL for me to personally keep track of and attempt to manage it all.
In fact, I have so many projects right now (about 20), I can hardly keep track of those alone. I now use an internal website where I use the WIP Wiki 3 to keep track of projects and all the notes related to them.
However, for worldwide REBOL projects, including those related to R3 development, the situation is more complex. I would classify it right now as a bit chaotic.
So that's a problem; now what's the solution? The perfect solution (for me) would be a web-page that lists each project along with status, who's leading the development, and when something was last done. It could also be for "wish projects" (things we want, but don't yet have developer commitments), as well as bounties, if so sponsored.
Yes, originally, I wanted DevBase to do this. But, I just don't have the time.
So, I need your help identifying an existing open software projects website that we could rally around for REBOL projects. This approach not only gives everyone access, also adds some visibility to REBOL overall.
Of course, whatever we pick, it must be possible to see a list of all REBOL projects and the status of each project... that's my primary requirement.
Any suggestions?
Example Projects...
In addition to the Host-Kit, a few projects that are high on my R3 list are:
- Mezz-plus function package - it allows us to remove some of the mezz functions from the primary boot, but let's us include them in the exec binary as an internally loadable module. For example the CGI functions we commonly use on servers would go here.
- Network protocols - Graham has written several of them for R3, and Gabriele wrote HTTP, but we need to collect them into a central project, an figure out what else is needed and who wants to do it.
- Improved Win32 Console - this is a C project, and we've got the R2 console to begin with.
- Proxy server support - the host kit provides the TCP/IP interface modules, and that's the best place for developer to add the proxy connections. Getting the main proxies working is not a big project, but help is needed for testing.
- Database interfaces - MySQL, SQLite, etc.
- Library interface - we've talked about this before.
And, there are many others.
Update 12-Jun-2010
I should stress that simpler is better. We do not need the classic project management system with all the administration duties and such (because that's not an effective approach for community-based project development.)
What I envision is a listing of projects that can be suggested by or implemented by anyone who's interested. The main purpose of the list is to make developers aware that a need exists for each project. For example, a better R3 console.
This is important because if the full development community can see the list, they may find that they can contribute to projects in one way or another. In addition, allowing anyone to post a project makes it possible for developers to request the implementation of something that is important to them (but perhaps not to others), even if they don't intend to implement it themselves.
And finally, some of the projects will "pop up" as being features we may want integrated into R3 itself. So, the list gives us a stream of improvements to the capabilities for all users.
The bottom line is that the result is more of a communication method than a management mechanism. That's what I'm interested in.
23 Comments Comments:
Graham
11-Jun-2010 14:11:22 |
If you've identified the solution as a web page, just create one on one of the wikis now running where people have access, and we can add the projects.
| Graham
11-Jun-2010 14:12:52 |
However, I think it is clear that R3 needs a project manager and such pages make poor proxies for this purpose.
| Carl Sassenrath
11-Jun-2010 14:22:18 |
On wiki usage: I was looking for a method more tuned to the goal. The open wiki concept proved itself to be limited when used in an informal way.
On PM: we need multiple "managers", which I'd hope we get in this approach. Take any one of the above projects, and it needs someone to manage it, otherwise it lands on my lap, appended to a deep queue and quite frankly, never to be seen from again. | Graham
11-Jun-2010 14:29:42 |
(at)wiki - that's because people who were editing the pages didn't know what they were talking about. One past failure does not predict the future. I suggest using the rebdev permissions scheme to allow access to editing.
(at)pm - you've structured it so that ultimately everything ends up in your lap. Whether you decide to do anything about it determines the success or otherwise of the R3 project.
| Carl Sassenrath
11-Jun-2010 15:36:07 |
Wiki - will work for now. At the very least, they'll get listed.
PM - not structured that way by intention, but more by assumed responsibility. The buck must stop somewhere. (The r.net wiki situation was a good example of that as well.) BTW, I'm entirely open to suggestions for how we can improve it (in R3 chat, not here.)
| Vladimir Jankovic
11-Jun-2010 23:26:31 |
We use Trac combined with mercurial source version control system for python code but it works well with rebol scripts too:
http://trac.edgewall.org
http://mercurial.selenic.com
| Gabriele
12-Jun-2010 2:30:31 |
Carl... I assume you're hoping Reichart does not read this? :-) | DideC
12-Jun-2010 3:16:02 |
I was on the way to say something like Gabriele, but more explicitly !!
I think you understand what we mean and what we think about, don't you ?
Tips : it start with a "Q" ! | Carl Sassenrath
12-Jun-2010 8:51:54 |
Gabriele, DideC: I think he's kite surfing... but perhaps with a waterproof handheld device.
But, joking aside, it does have many advantages. However, like AltME, all work is hidden from the world... so new users can't see a nice summary page that shows a list of active projects with developer names and activity levels (for example as found in sourceforge, codeplex, or berlios). | Carl Sassenrath
12-Jun-2010 9:47:16 |
Main article updated with additional notes. | Graham
12-Jun-2010 14:22:39 |
We have the situation where we have a number of independent R3 projects that are ongoing. There's no way you're going to convince people to switch away from their favourite revision/tracking system whether it be SVN, Git, Trac or sourceforge to a single common system. So, realistically all you can do is create an index page which we can edit to let people know where all this stuff is. At this stage I know of about 4 different projects. A web page can handle that.
Either you create it on rebol.com, or we create it somewhere else ... up to you.
| Graham
12-Jun-2010 14:59:37 |
I see the projects page now at http://www.rebol.com/projects.html
So, how do we edit it to add details of our projects?
| -pekr-
12-Jun-2010 16:08:31 |
This effort is kind of useless, imo. It helps nothing. Better please outline, what is your plan to get R3 finished and released, and what needs to be done the get us there. | Henrik
13-Jun-2010 3:18:31 |
My point of view:
And finally, some of the projects will "pop up" as being features we may want integrated into R3 itself. So, the list gives us a stream of improvements to the capabilities for all users.
In my opinion, if features emerge from projects, people will speak up in Curecode or on R3 chat, at least after a thorough discussion on AltME. This method works very well and people like Brian Hawley are excellent mediators here to avoid "junk" from being suggested.
Although I realize that we may not be the only channel to speak up, a project list seems a very inefficient and inaccurate way of gathering such information. It seems like it's a way to ask whether people need SSL or graphics on OSX or trying to get a clue on what to "fix first" to satisfy false needs on a project as complex and diverse as R3.
I think most people would just prefer that you follow your original plan and appropriately check the boxes on the plan as you finish the features. That's it. That is the shortest path to a usable, finished product. Anything else signals insecurity and indecisiveness and will ultimately be a reason not to use R3.
Right now, R3 just needs to move forward with the host kit, just as you planned. There is a good number of people simply waiting to get the host kit, so we can get some real work done. | Paul
13-Jun-2010 7:10:31 |
I can see Reichart about now sitting on the beach in Maui surfing this blog on his handheld and screaming QTASK!
| Brian Tiffin
13-Jun-2010 10:45:37 |
A +1 ditto meetoo on Qtask.
| amike
14-Jun-2010 2:25:23 |
If you just need one HTML page, why not to test a "Kanban Board" like this sample application ?
| -pekr-
14-Jun-2010 5:07:40 |
I totally agree with Henrik. First thing we need is to get "product" out of the door, released. And for such a purpose, following checklisk would be sufficient:
http://www.rebol.com/priorities.html
Once we are in beta, we can think of additional/related projects. IIRC, I even suggested to extend CureCode, to contain milestones, so that such "priority lists" could be assigned to planned milestone releases. And it could be even cross-linked with projects somehows.
But - the project page does not answer the organisational question of - what happens next? When are we back to regular R3 development? What features is RT working on? Where's our help/attention needed right now? | Peter
14-Jun-2010 17:53:36 |
Personally, I think a summary list of major sub-projects and projects related to the R3 core project is very useful.
It doesn't make sense to me to include these high-level activities in REBOL3 CureCode. They would be better handled in CureCode as separate projects. (But a summary would still be needed.)
Also, as Graham pointed out, people may not want to move to CureCode from their current tracking tool.
| -pekr-
14-Jun-2010 23:51:11 |
Went thru the list. Carl, please add 'call function rework. It is pretty much useless in its current R3 state. We need call/wait/output at least, or we are not able to catch the output. That way, guys can do at least primitive DB drivers wrapping e.g. sqlite.exe.
It is under CureCode ticket #1223 | Oleg
15-Jun-2010 18:51:18 |
Carl, take a look at www.actionmethod.com - it might be just what you're looking for. | Felix
15-Jun-2010 20:45:04 |
Collabtive seems very good,
seems to be open source, have not read terms
found at Wikipedia | Carl Sassenrath
16-Jun-2010 14:03:23 |
Thanks for all the suggestions.
I agree that what we need isn't specifically a piece of software... what we need is to agree on a specific process that is lightweight and easy to handle/track. We don't want admin overhead, etc. We want as many developers to use it as possible.
Robert Muench has suggested the Scrum process, and that's the topic of my next blog.
If we agree, then the next highest priority is to figure out the best way to implement the process. It could be Qtask or whatever the team agrees on as the best approach.
|
Post a Comment:
You can post a comment here. Keep it on-topic.
|
