Thanks for the advice, I'll keep it in mind.
I would like to add something for JFC who I replied to earlier: Wikis are
only a small part (a small tool they can use) of the community website that
I want to make. They don't form the main core of the website.
On Mon, Feb 2, 2015 at 8:29 PM, George Barnick <georgebarnick(a)gmail.com>
wrote:
Instead of having all the communities on the same
MediaWiki wiki separated
by page names, you can run multiple wikis off one MediaWiki installation.
At Brickimedia (see
http://www.mediawiki.org/wiki/Brickimedia) each wiki
runs off one MediaWiki installation and just loads a different
LocalSettings file and a different database based on what subdomain is
typed in. This requires some extra apache/nginx configuration but if you
take a look here you might understand it:
https://github.com/Brickimedia/LocalSettings/blob/master/LocalSettings.php#…
On Mon Feb 02 2015 at 9:00:48 PM Jay R <jr65322(a)gmail.com> wrote:
Thank you for your thoughts! Our projects are
definitely different but
its
still nice to know that someone is trying to make
something positive.
I will have to get help about what to do next.
Jay
On Mon, Feb 2, 2015 at 7:10 AM, JFC Morfin <jefsey(a)jefsey.com> wrote:
At 00:26 02/02/2015, Jay R wrote:
> I've been creating a job description for making a non-profit ad-free
> website which will allow people to setup their own communities where
they
>> can work on solving problems relating to specific areas. Different
tools
> will
be provided to them including a custom-built task management
system,
a
forum and a wiki.
I am working on a similar Libre concept I call a cyberagora.
Unfortunately
in French (
http://cybagora.org).
The idea is the smartest conviality afficient support of "agoras"
(cities,
wg, communities, personal windows to the world,
mathematical concept,
etc.)
>
> The whole website will be "wiki" based i.e., people will
collaboratively
>> work together and edit task items which
are not Wiki pages. For
example
it
>> may be a row in a database of another table.
>>
>
> My idea is of a flexible federation of SQLite based mediawikis (as a
> start), and eventually a cloud of "intellipages" (i.e. smart
independent
> json based wikipages) virtually gathered
together through a DDDS (
>
http://en.wikipedia.org/wiki/Dynamic_Delegation_Discovery_System)..
This
> way I have no hosting to consider and
maximum flexibility.
>
> Anyone can fill out a form and a new community is created along with a
>> wiki
>> of their own. So each community will have access to its own set of
wiki
>> pages. They may have 5 or 20 or 100
pages. In the long term there may
be
>> 100's or 1000's of communities
if the website is a success. The URL
of
a
>> wiki could be something like:
en.Solveissues123.org/Community6543/Wiki
>>
<http://en.Solveissues.org/Community6543/Wiki>
>> The issues are:
>> (1) User database. I'd like to keep a common user database so people
can
>> login once and edit other community
wikis.
>>
>
> I suggest a different approach: by capacities. Can access an
intellipage
only
those with the necessary capacity. They acquire the capacities
through
a DDDS service (like the DNS) for a limited
duration.
(2) Interlinking between various wiki communities
> (3) Sidebar content for each community so they have their own
navigation.
>> (4) Communities may be set up in their own language so a wiki may have
>> its own language.
>> (5) There may be customization for aesthetics.
>>
>
> OK for all of this. This is part, from my POV, of the VGN (Virtual
Glocal
> Network) contextual parametring (the
participating sites to a
relational
> space).
>
> My idea is as follows:
> - the intellipages follows a common formating JSON standard.
> - they are registered by their owner in one or several relational
spaces
> - these relational spaces are supported by
people's VGN with their
local
global or
global local constraints (like a format, verification tools,
Quality control; langages, etc.).
It will be like Wikia but I have to reserve the sub-domains for
languages.
>> I want to use Mediawiki and it will have to be customized to a large
>> extent.
>> I have different options:
>>
>> 1. Use one Mediawiki for the whole website (so one database). Let
people
>
separate their community wikis by using different page titles for
example
> [[Community6543/Title of Page]]. They would
have to use a similar
notation
>> to keep their categories separate. There will be one user database so
>> that's good since anyone can edit a page from any community.
>> The issue are the sidebar and other navigational links and language
>> options. I could get the installation fully customized and change it
so
> they
need to edit [[Community6543/Sidebar]] to show their own
navigation.
>>
>> 2. Use one mediawiki for each community. They can all use the same
user
>
database ($wgSharedDB). Not sure how to manage interlinking here. Any
> other
> issues I need to think about? This may be a good solution since a
> community
> may have its own language.
>
> 3. Use a 3rd light weight wiki software that provides basic wiki
functions
>> (editing, page history, diffs). Is there anything like that available
or
>> would it need to be created from
scratch?
>>
>
> This is a good question :-)
> The best would be syntaxic/use compatibility with wikipedia. So the
best
> products of the personal/group wikis could
be copied to wikipedia.
>
> A sidenote: Any general advice on how to manage the individual forum
>> creation as well? I would not like to use the talk pages as forums but
>> rather an independent traditional forum for each community.
>>
>
> IMHO you need everything you can findimagine (blogs, mailing list,
fora,
heuristic
maps, etc.) and be totally language independent (except js as
the
bowsers' language).
Any advice would be appreciated. Or if you know where I can get
> professional help in creating the job description for this website let
me
> know. I can then post the job at a
freelancing website to have the
website
>> made.
>>
>
> Not so easy. I would advise for each tool to look first at all the
> parameters being supported (mediawiki, wordpress, etc.) to make sure
you
do
> not forget any of them. Then to compare them from one tool to another
and
establish
your own common parameter tables. Then review each
functionality
in a multiple tools context, to see what can be
aggregated or extended.
From there you will need to design a system architecture taking care of
replications/security/backup/restorations and of the mix of the
different
databases (DDDS, Semantics) included. At the same
time you need to
imagine
how you can make it commercial (business and
non-profit alike) and
support
> extensions by third parties (API).
>
> Then, not so much to write a job desciption, but a protocol, like an
RFC.
> Then to start with a prototype, and test it.
Then to add foreseen and
new
features
you will have discovered from experimentation.
Just half a cent, for a big project.
jfc
Jay
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l