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 <[email protected]> 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#L81-L183 > > On Mon Feb 02 2015 at 9:00:48 PM Jay R <[email protected]> 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 <[email protected]> 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 > _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
