Community

General discussion

Locked

Workspace. addon idea...

By Jaqui ·
and Question..

When is the Shared Project functionality going to be implemented? any timeline on it?

for a test of that, why not have some members collaborate on a site script that duplicates TR's, with the feature requests that have been most frequently asked for.

it may require adding something like cvs or subversion tools to the workspace though.
[ or one member putting a version control server space up for it. ]
if that happens then that same box could also be used as a platform for testing the script with.

since this script could become part of the foundation for further TR improvements, I doubt that such a project would ever become visible to the general membership, which is why I posted the idea in here.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

I'm OK with recruitment

by Jay Garmon Contributor In reply to You're on

There would probably be some online form that we'd have to have participants fill out to get access to the Wiki spec--just so we have an idea of who is actually working on this--but I have no problem with you individually approaching non-TRIs. Anybody who is passionate enough about the product to commit time and resources to this effort would qualify as an Insider in my book. If they are serious about the commitment, we might actually extend them full TRI privileges.

In any case, find me a reliable, competent, passionate build team of TR members, and I don't care where they come from.

Collapse -

well we have the 6 + more

by Jaqui In reply to You're on

in alphabetical order:

apotheon
Hal9000
Jaqui
jardinier
jdclyde
Tony Hopkinson

now to get enough bodies to actually complete it.
would need another 12 at least. [ in my opinion ]

well we can add:

faradhi
stargazerr
tjsanko@...

that's 9. I say 20 is a good number to aim for to have a solid team.

Collapse -

More is good, eventually.

by apotheon In reply to You're on

Before we start recruiting in mass quantities, it might make sense to start hashing out basic plans and requirements. Such decisions are usually better made by small numbers of people. If later-joining participants have suggestions for how to change our specs, that's great: I'd favor something closer to an "agile" approach than old-school corporate dictated requirements. We should just have some kind of direction in place before muddying the waters with more "democracy".

Collapse -

I agree that

by Jaqui In reply to You're on

we need to get what is required, what language to script in, etc hammered out before we get to many people.

right now there are 7.

we do need to get the requirements from TR as part of that, since without those, we would be working to no real purpose.

We know that discussions, TQ&A, downloads, webcasts, news, wiki/blog, storefront [ books / cds ], collaboration are wanted, but what else do they want?
what features that have been requested by members are going to be implemented, and in what order?

and the big one, which of the open source licences to use?
the gnu-gpl is, in my opinion, not an option, it's to restrictive.

Collapse -

Why PHP?

by apotheon In reply to a wiki

Perl outperforms PHP somethin' fierce, and is in general a better language, particularly for CGI stuff. I'd probably aim for PHP if I was going to do markup-embedded code, but not for CGI, by choice.

Still, I'd rather work with PHP/CGI than Java.

Collapse -

that's just it

by Jaqui In reply to Why PHP?

the entire project is in discussion stage and everything is up in the air.
I do have php scripts right now that can be used as a base, for most aspects of the script.
I even have a script for online collaboration designed for writing articles, ecommerce script, discussion script.

all of which could be used as a baseline for the issues / concerns to be addressed and idea sparks for the actual code.

I posted the table design for the discussion script in a reply to jd in this thread.
basic, yet covers most aspects that would be needed in a more robust discussion table.

Collapse -

For what its worth...

by Jay Garmon Contributor In reply to that's just it

There's some internal development love for Wordpress, which is written in PHP. We're current using TWiki for our wiki stuff, and its written in Perl, but it doesn't scale at all. MediaWiki (AKA Wikipedia) is written in PHP. A Wordpress front end bolted onto a MediaWiki database might be the holy grail, but that's just idle chatter.

Collapse -

about MediaWiki

by apotheon In reply to that's just it

Having been amongst the developer chatter for MediaWiki, I can say with some certainty that it seems the reason MediaWiki continues to be developed in PHP is that nobody wants to start over with Perl, Python, Ruby, or C/C++, despite developers often wishing it was written in one of those languages instead for purposes of scalability. In fact, if it were started over from scratch today, I'm pretty sure the thing would overwhelmingly have support for being written in Python instead.

Damn, I shouldn't have said that. Now someone's going to want to do this TRI project in Python, and I'm going to have to get bandages for my bleeding eyes from looking at Python code.

Collapse -

I'd be interested in contributing

by Tony Hopkinson In reply to Workspace. addon idea...

in my copious free time.
Be a nice step into an open source project for me.

Collapse -

so that then

by Jaqui In reply to I'd be interested in cont ...

is You, Apotheon and I, probably JD as well.
2/3 of the number needed for getting it started with TR approval.

seems like it will become a go. :)

Then we would have to agree on the language to be used, if TR doesn't demand we do it in java server pages. [ hoping that they don't ]

then the user interface, within the constraint's that TR will set.

going to be quite heavy in the xml for the blog /wiki /rss feed aspects.

Related Discussions

Related Forums