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
