Hi,

I hope people don't feel I'm hijacking this mailing list (I'm not a developer). I wanted to participate in the website redesign discussion. I'm not officially involved, although I'm hoping to be! (I've submitted a mockup proposal - duckgoesoink.deviantart.com, and would love to be further involved.)

My comments concerning Steven's structure proposal:

I think the user groups you've defined are good (it's so important to define the target audience, so as to avoid aiming for the wrong crowd - design-wise, content-wise, etc). And the focus on activities could make navigation simpler, especially as the user groups will probably see some overlap. I generally like the proposed menu structure.

However I'm a bit anti-wiki - in my experience if they're not wikipedia.org they're usually too chaotic for normal people to make any sense of, they're randomly updated, have very inconsistent writing styles, have many unfinished pages, and information can get scattered/duplicated. Looking at the current wiki, there is a lot of general information, much of which would be useful to have on the main website if tidied up (I assume the website would be updated regularly by people assigned to keep info up to date).

Anywho, just my two cents.

Cheers, Hinerangi Courtenay (duckgoesoink)

On Tue, Dec 14, 2010 at 7:55 PM, Ian Caldwell <inchosting@...400...> wrote: personally I have a beef with the wiki, I see no real reason to keep the wiki.... In my opinion it serves no purpose if our docs are good enough, and kept in SVN they can be updated easy enough by the people that need to.... It's crazy. Thanks, Ian Caldwell

On Tue, Dec 14, 2010 at 7:51 PM, Ian Caldwell <inchosting@...400...> wrote: hello, This email is sent on behalf of Steven M. Ottens.

So I think we shouldn't try to get the wiki into Django. The wiki is the wiki and people are reasonably aware of the principle of a wiki. That being said, currently the wiki is a whole separate entity which I never ventured into until today. There is a wealth of information there, but it is hidden behind the simple link 'wiki'

So I don't think we should try to create a design which forces the wiki to behave as the rest of the site, but to create a separate (but similar) design for the wiki to make it clear for the users they are in the wiki with a clear way back to the site. Also we should make more appropriate links from the site to the wiki. There are many topics in the site which are also discussed in the wiki, we should link to those. I came up in my restructuring mail with 'landing pages' on various topics. Having various main pages in the wiki which reflect the menu-structure in the website might create a stronger bridge between the two, without restricting the wiki to the website-structure.

Regards Steven

note: I know making a difference between the wiki and 'the website' isn't entirely fair, the wiki is part of the website etc etc. It is just a quick way to get the message across (I hope)

I agree with this viewpoint - a wiki would still be useful for drafts, collaboration, etc.

Finished information for users at least, could be published to a guide-like user documentation. When I said I was anti-wiki, I meant from a "user" point of view - someone who is new to Inkscape generally needs a more structured approach to documentation than a wiki (such as a "Getting Started" section as you mention).

Cheers, duckgoesoink

On Dec 15, 2010, at 5:28 PM, Néstor Díaz Valencia wrote:

Hi,

Though I just wrote I agree with Steven, now I feel I didn't say anything productive.

I think the wiki should go into the django site, but any information stable enough should go to an structured place meanwhile experiments and drafts may stay in a wikilike place.

I wouldn't say I'm anti-wiki like Ian expressed, in my experience wikis are useful for information developing and collaboration in a moving forward enviroment (kind of trunk + branches subversion for code), but for final users you release one and just one tar.gz (a subversion tag) Sorry for the poor comparison.

The menu structure is similar to the mindmap some of us elaborated plus de "Getting started" section which I feel is good to have.

Cheers, n3storm

El 15/12/10 09:18, Hinerangi Courtenay escribió:

...

However I'm a bit anti-wiki - in my experience if they're not wikipedia.org they're usually too chaotic for normal people to make any sense of, they're randomly updated, have very inconsistent writing styles, have many unfinished pages, and information can get scattered/duplicated. Looking at the current wiki, there is a lot of general information, much of which would be useful to have on the main website if tidied up (I assume the website would be updated regularly by people assigned to keep info up to date).

Anywho, just my two cents.

Cheers, Hinerangi Courtenay (duckgoesoink)

2010/12/15 Krzysztof Kosiński <tweenk.pl@...400...>:

2010/12/15 Hinerangi Courtenay <duckgoesoink@...400...>:

...

I agree with this viewpoint - a wiki would still be useful for drafts, collaboration, etc.

Finished information for users at least, could be published to a guide-like user documentation. When I said I was anti-wiki, I meant from a "user" point of view - someone who is new to Inkscape generally needs a more structured approach to documentation than a wiki (such as a "Getting Started" section as you mention).

A wiki does not preclude a structured approach to information, particularly with newer version of MediaWiki - see wikibooks.org.

Agreed.

What is needed is a concerted effort to organize the information available on the wiki, and remove outdated information.

I absolutely agree. We seem to have lots of people interested in replacing the wiki or otherwise showing some form of interest at the moment. Energy and enthusiasm is good and we need to tap into it while it's there. So really, it seems like the main areas that need to be dealt with are some restructuring/reorganizing where it makes sense, removing truly deprecated information, updating things that are still partially accurate, and what else?

Do we have any takers for the "overhaul" stuff as opposed to rebuilding? I know I will be busy through the holidays, but after that could commit about an hour a day to working on some of this.

Cheers, Josh

On Dec 15, 2010, at 6:10 PM, Krzysztof Kosiński wrote:

A wiki does not preclude a structured approach to information, particularly with newer version of MediaWiki - see wikibooks.org.

The problem of insufficient documentation will not magically disappear if we move it somewhere else. What you perceive as a problem with the wiki is in fact a problem of insufficient manpower. It doesn't really matter where the documentation is stored; storing it on the wiki has a distinct advantage in that it has a low barrier of entry, so anyone can improve it. If we remove the incomplete documentation from the wiki we might end up not with better documentation, but no documentation at all.

What is needed is a concerted effort to organize the information available on the wiki, and remove outdated information.

Fair enough. Taking the wikibooks.org example, their information is clearly laid out and organized into easily readable sections, with drafts clearly defined as such. Making edits is easy and anonymous.

The current wiki is difficult to navigate (visually), and how to edit is not too obvious (instructions hidden behind WikiSyntax I believe). Getting back to the main website is confusing. I would gladly help tidy up wiki documentation but don't feel in a position to do so (I use Inkscape daily but am just a user - I don't know much about the technicalities of the project nor about writing/editing user documentation).

Also, some information may be easier (or more appropriate) to organize on the main website (long sections of general information). There is some good content but when it's on a wiki it can feel like unstable (therefore unreliable) information to a new user.

Cheers, duckgoesoink

Hi Jasper,

maybe out of the scope of the website refactoring, but can it be that if we standarise documentation around reST (RestructuredText) and Sphinx http://sphinx.pocoo.org/ we may end up with:

a- Great browseable code documentation b- Nice drafts, discussions wiki (we make a django with sphinx rest files backend) c- Nice end user documentation including offline consulting (html, pdf, etc)

And the flow a <-> b <-> c <-> a , or information lifecycle will go smooth.

Anybody else loves sphinx? :)

Cheers, n3storm

El 15/12/10 10:52, Jasper van de Gronde escribió:

On 2010-12-15 04:55, Ian Caldwell wrote:

...

personally I have a beef with the wiki, I see no real reason to keep the wiki.... In my opinion it serves no purpose if our docs are good enough, and kept in SVN they can be updated easy enough by the people that need to.... It's crazy. Thanks, Ian Caldwell ...

We indeed have documentation that does not need to be on a wiki (and a lot of it isn't on the wiki), and you're completely right that for a lot of documentation the wiki simply isn't the right place.

However, that's not all that's on the Wiki. It also provides a place for people to write proposals, discuss (in a more structured manner than on the mailing list) and keep track of things. And it has a relatively low barrier for entry, which is quite crucial in my opinion.

I'm not saying that it would be impossible to live without the Wiki, but it's not just an accumulation of documents and definitely does serve a purpose. It could be improved, and I agree that some things may not belong there, but eradicating it altogether should not be done lightly.

Also, if we were to move a lot of things away from the Wiki then we really should think about making it easier to update the website. I wouldn't have a clue how it's done.

BTW, if you have documents that can be viewed on-line, in some easily editable syntax and community editable through BZR, what's the difference with a Wiki? (Except that you can't easily link between documents in BZR, would need to agree on a file format and that you would force anyone wanting to edit a document to install BZR and some editor.)

---

Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Here's one big long response to most of the contents of this thread. Hope you can work out what I mean; I wrote the responses to the first one yesterday and the rest today.

-----

On Wed, Dec 15, 2010 at 8:52 PM, Jasper van de Gronde < th.v.d.gronde@...528...> wrote:

We indeed have documentation that does not need to be on a wiki (and a lot of it isn't on the wiki), and you're completely right that for a lot of documentation the wiki simply isn't the right place.

Absolutely.

However, that's not all that's on the Wiki. It also provides a place for people to write proposals, discuss (in a more structured manner than on the mailing list) and keep track of things. And it has a relatively low barrier for entry, which is quite crucial in my opinion.

Whoever said proposals and discussion has to take place in a wiki? There can easily be other ways of doing that. (The general idea of the wiki workflow can remain, though. I just mean I think it should feel more like part of the main website in general, though I'd have to see how it ends up feeling and reacting; it may not work well. development/proposals/* or something like that.)

I'm not saying that it would be impossible to live without the Wiki, but

it's not just an accumulation of documents and definitely does serve a purpose. It could be improved, and I agree that some things may not belong there, but eradicating it altogether should not be done lightly.

Definitely; I'm suggesting that a significant quantity of what's there is either moved into developer region or put in the main part of the site.

Also, if we were to move a lot of things away from the Wiki then we

really should think about making it easier to update the website. I wouldn't have a clue how it's done.

BTW, if you have documents that can be viewed on-line, in some easily

editable syntax and community editable through BZR, what's the

difference with a Wiki? (Except that you can't easily link between documents in BZR, would need to agree on a file format and that you would force anyone wanting to edit a document to install BZR and some editor.)

My intent is to keep this backed by the file system and a Bazaar repository. When people think of this, they seem to think that this implies that you'll require Bazaar to be installed. *It doesn't need to be that way.* The website can provide a normal web interface for document editing which modifies and commits content in the backend. (Google Code's wiki system works that way and one or two CMSes are now doing that.)

Concerning the format, clearly the format used must be decided upon; my personal recommendation for this is using reStructuredText; it's clean, neat and easily understandable. There are then two link styles that can be used;

* Wiki style "page title is in the URL". This is not my preference; I like my slugs to be brief and concise. * Use concise slugs; /wiki/communities (rather than /wiki/International_and_Local_Communitites (concerning that page on the existing wiki - what exactly does "local" mean!?). Just like the rest of a site always is. (Or better still, integrated into the main website as /community/something)

Internal linking can be done easily.

I just went and looked at the front page of the wiki. In my opinion, with the website easily editable in a reasonable format (i.e. not HTML as it currently is), and with the site restructuring we're planning on doing, *none of it belongs in a wiki.* "About Inkscape"? What was that doing there in the first place? "User Documentation"? That all fits in /learn

----- (The portion of the email above was written before reading further in the conversation. It now turns out that Néstor likes RST as well!)

2010/12/16 Néstor Díaz Valencia <nestor@...2495...>

maybe out of the scope of the website refactoring, but can it be that if we standarise documentation around reST (RestructuredText) and Sphinx http://sphinx.pocoo.org/ we may end up with:

a- Great browseable code documentation b- Nice drafts, discussions wiki (we make a django with sphinx rest files backend) c- Nice end user documentation including offline consulting (html, pdf, etc)

And the flow a <-> b <-> c <-> a , or information lifecycle will go smooth.

I was intending to do this not with the developer documentation but with most of the content on the main website and the hypothetical wiki; those pages that need to be HTML (e.g. front page, download page) can still be HTML content

(But please, it's reStructuredText, not RestructuredText)

Anybody else loves sphinx? :)

Yay!

-----

2010/12/16 Josh Andler <scislac@...400...>

2010/12/15 Krzysztof Kosiński <tweenk.pl@...400...>:

...

What is needed is a concerted effort to organize the information available on the wiki, and remove outdated information.

I absolutely agree. We seem to have lots of people interested in replacing the wiki or otherwise showing some form of interest at the moment. Energy and enthusiasm is good and we need to tap into it while it's there. So really, it seems like the main areas that need to be dealt with are some restructuring/reorganizing where it makes sense, removing truly deprecated information, updating things that are still partially accurate, and what else?

Do we have any takers for the "overhaul" stuff as opposed to rebuilding? I know I will be busy through the holidays, but after that could commit about an hour a day to working on some of this.

I think it would be helpful doing this in a decided format in a repository, rather than in the wiki; really, starting preparing the content migration before the site is ready. We'll need to pull the content from the wiki anyway and reformat it. So far we have two liking reStructuredText and no other suggestions so I'd recommend using that format. (Besides which, it's a simple and readable enough format that migration is pretty easy.)

-----

On Thu, Dec 16, 2010 at 4:47 AM, Jon Cruz <jon@...18...> wrote:

I've been in the situation in the past where we've had a wiki replaced by the "just as good" alternative. Problem is... a wiki is also very much about the usage and workflow, and even a nicer CMS like Alfresco or such is just not the same.

I think we can improve upon it by making it web-editable and text editor-editable (beyond testing to make sure it works, I know which I'll use; give me a text editor any day - most people seem to normally write their text in a decent text editor anyway and just copy it into the website's textarea when they're done. Keeping it - or at least the possibility of keeping it - entirely in a text editor and console is a great improvement in my opinion.)

Smaller bits of information, cross-linking and content evolving over time

are a few keys.

I'll be taking all of these into consideration; I believe we can do it well.

-----

On Thu, Dec 16, 2010 at 8:02 PM, Hinerangi Courtenay <duckgoesoink@...400...

wrote:

Taking the wikibooks.org example, their information is clearly laid out and organized into easily readable sections, with drafts clearly defined as such. Making edits is easy and anonymous.

And currently the Inkscape wiki is not anonymously editable. And that is a feature I *definitely* intend to keep.

The current wiki is difficult to navigate (visually), and how to edit is not

too obvious (instructions hidden behind WikiSyntax I believe). Getting back to the main website is confusing. I would gladly help tidy up wiki documentation but don't feel in a position to do so (I use Inkscape daily but am just a user - I don't know much about the technicalities of the project nor about writing/editing user documentation).

Indeed, the current system is cumbersome and unfriendly. I haven't updated information on the wiki a number of times because it was just too hard... if it had been in a repository, I would have; I think I did finally create an account and have edited one or two pages but I really can't remember well... my experience with the current wiki is almost entirely negative, really.

Also, some information may be easier (or more appropriate) to organize on the main website (long sections of general information). There is some good content but when it's on a wiki it can feel like unstable (therefore unreliable) information to a new user.

I agree entirely with this. As noted earlier, I think just about all of the primary content in the wiki (the stuff linked to from the front page) belongs on the main site. I imagine the reason it hasn't been there is because it's just been too hard to do. The old system was very inflexible.

-----

I've run out of emails to comment on!

As is usual in long emails I write, they tend to be significantly fragmented. Please ask if you don't understand or want me to explain something further, etc.

Regards,

Chris Morgan.

2010/12/17 Jasper van de Gronde <th.v.d.gronde@...528...>:

So why not simply move most of our site over to the wiki? Then we can reorganize and restyle that, making sure that it becomes easier to navigate and contribute. That way our site becomes more accessible and better orgaized, while still getting the advantage of being able to easily edit it.

I'm not sure about this. It's rather hard to code nice visuals in MediaWiki because you can't rely on CSS - you have to use inline styles everywhere. I'd rather keep the wiki for documentation.

What definitely needs to be addressed is the custom MediaWiki skin we are using. It's ugly, unreadable, and the page title is missing - the first thing you see on most pages is a table of contents.

Regards, Krzysztof

Hi all,

Since I've started the discussion on both the website structure and the wiki (through Ian - thanks) I feel it is time to give my summary of the discussion and advice what to do next.

In general it is recognized that the site (main and wiki) need an overhaul, both its design and its content. There is no consensus how this overhaul should be done. Everything between putting everything in a wiki or in a CMS, leave the design and do the content first or just put a new skin on top of the content has passed the revue.

Various important issues came up: -The status of current content is unclear -Easy editing is required -Unified login is required -How do we proceed

On the first topic: this is something that has to be cleared up, regardless of if and how the site will be overhauled. As taken from the discussion: Krzysztof: What is needed is a concerted effort to organize the information available on the wiki, and remove outdated information.

Josh: So really, it seems like the main areas that need to be dealt with are some restructuring/reorganizing where it makes sense, removing truly deprecated information, updating things that are still partially accurate, and what else?

Chris: I think it would be helpful doing this in a decided format in a repository, rather than in the wiki; really, starting preparing the content migration before the site is ready. We'll need to pull the content from the wiki anyway and reformat it.

So this is task one, although I would like to add it is information both on the wiki and the main site. I agree with Chris that it would be smart to do it in such a way that it can be used in the content migration.

On the second topic: Wiki [1] stands for a website that allows the easy creation and editing of any number of interlinked web pages. However, this does not mean that it needs to run on mediawiki or other software with 'wiki' in its name. Also easy editing is a rather subjective thing. Personally I find Wordpress' rich text editor with autosave etc a much easier way to edit than mediawiki with its wiki-syntax. However, we require something where (once logged in - anonymous edits are a thing of the past unfortunately) you can click on edit and get on your way as such keeping the wiki-workflow.

From the discussion:

Jon: Problem is... a wiki is also very much about the usage and workflow, and even a nicer CMS like Alfresco or such is just not the same.

Chris: I think we can improve upon it by making it web-editable and text editor-editable

So task two is to make sure that whatever we build, it needs to be easy to edit existing and new content, both in getting to the edit bit and the actual editing.

On the third topic: this is a bit of a no-brainer. It is in the design document [2]: '• LOGIN as with http://meta.osqa.net/account/signin/ (allows various accounts to login - Google, Facebook, Twitter, etc.)' this would make it even possible for those who want to not create a new account to edit, but use an existing one.

On the fourth topic: I don't believe in design by committee [3] so I don't think we should keep on discussing until we have a consensus on how to proceed. There is a team assembled by Ian who are motivated and skilled enough to take on the redesign and rebuilding of the site. The deadline of the design submissions was yesterday, a winner will be announced soon, so we can start implementing that design. It will be done in Django, with task two in mind.

So task three A is for the website team to get cracking and task three B is for the rest to have a little faith in us and have a look at task one :)

I hope I have addressed all important issues people have discussed. I'm open for any comments or feedback, but do realize that we need to start working and this will be our starting point. In my experience it is more useful to discuss some actual object than just the realm of possibilities. As Chris said earlier: "At present we're discussing hypothetical cases and new things that haven't been seen and so can't be assessed fairly."

On a last note: although I'm part of the team, I've written this on a personal title. 'I' really means me and my opinions and 'we' generally means the team and shouldn't express an opinion, just tasks and obligations.

Regards, Steven

[1] http://en.wikipedia.org/wiki/Wiki [2] https://docs.google.com/document/pub?id=1K2O-gRdbkP0XATykk6LcPo6O5-JdQzK4QmP... [3] http://en.wikipedia.org/wiki/Design_by_committee

Hi Krzysztof,

Don't take it personal please, I think your making an argument "ad hominen" with mediawiki used by thousands projects. There are others that not.

Nothing is technically broken so we shouldn't fix it. I can see, browse everything at inkscape.org, everything? not sure, because site search uses google and at this moment shows no results if I look up for "filters". If I search for "filters" there are no Page title matches If I search for "effects" the second one in Page title is "filter effects", that is not how a search engine in 2010 works and Dokuwiki search is more intelligent than this.

A user doesn't know if he or she is missing something and we cannot guarantee with actual deployment he or she will reach information properly. One part of interesting information is spread over a wiki and we should handle this: wiki gardening and moving everything stable to actual structured documentation, browseable and searchable.

Just to make this clear, I have been in Open Source communities for 10 years and I don't want this thread a drupal, mediawiki, whatever FLOSS, bashing.

Also, I don't think it's necessary to remind software has lifecycles, niche, bumps and so.

As someone says in this thread, there is a good momentum (meaning willing people) to create a nice community and documentation website for Inkscape. Some of us are not C++ coders so we will be pretty happy with python-django-js/html/css-sql migrating helping.

I can agree with you in planning this into stages: 1st, main site, then everything else and I think this is how we are going to do it anyway. Although it doesn't hurt to have the whole picture.

On the wiki syntax part, in my opinion you are not approaching the problem from a non-hard-core-wiki documentator perspective. Adding images to wiki is odd and loose linking can make big damage (e.g. Link to "Effect" page and "effect" page)

Also, I didn't say website documentators must learn reST, but it should be the common language, so in the website you write with a WYSIWYG and stuff is stored or ultimatelly converted to reST. It was only a suggestion anyway.

Just one __not personal__ thought, when you say

while your custom system would have only 1 user (inkscape.org) and 1 maintainer (you)

It looks to me you haven't developed with Django or any framework alike (RoR), if I'm not wrong I suggest you to have a look and see how this is not like building your own site from scratch.

Just for more django evangelization: http://www.openshotvideo.com/2010/10/new-openshot-website-launched.html

And my last words :) I would like to work these holidays too on this, I hope this aspects are settled down by someone because I am not going to argue/evangelize anymore. Just waiting for meetings or tasks assigment and moving forward.

Cheers, n3storm

El 19/12/10 18:22, Krzysztof Kosiński escribió:

I thought some more about this and I see we are quickly entering bogus-land.

Chris& other "let's change everything" people: *what is the point* of spending a lot of time on migrating all the information to some different wiki-like system that uses a different syntax, has different features and different everything? There is nothing of substance to gain. We end up with same not very well organized information, but this time in a custom system that might not have all the features we had in MediaWiki and has a different a syntax. MediaWiki is used by thousands of projects and has a lot of people working on it, while your custom system would have only 1 user (inkscape.org) and 1 maintainer (you). We are not in the business of writing and maintaining wiki software. Furthermore, many more people are familiar with wikisyntax than reST.

Single sign on is the only real advantage your solution would have, but instead of removing MediaWiki you can just use one of the authentication plugins for MediaWiki. http://www.mediawiki.org/wiki/Extension:CASAuthentication http://www.mediawiki.org/wiki/Extension:AuthDrupal https://bitbucket.org/toml/django-mediawiki-authentication/src

You essentially want to spend a lot of time to make something possibly inferior. WHY? Forget about the wiki for now, it's not broken. In fact, it would work extremely well if it had a better skin (e.g. the default one!). Fix the main site first, then we can start talking about the wiki.

To sum up my points:

1. Don't try to fix things that work very well.
2. Standing on the shoulders of giants is good.
3. Fix the main site first.

Regards, Krzysztof

---

Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2010/12/20 Néstor Díaz Valencia <nestor@...2495...>:

Don't take it personal please, I think your making an argument "ad hominen" with mediawiki used by thousands projects. There are others that not.

Ad hominem would be if I attacked Chris or you personally. This was something else - argument from popularity, which is not valid in general, but with FOSS it does have some merit. More users = (usually) more developers = better quality and less bugs.

Nothing is technically broken so we shouldn't fix it. I can see, browse everything at inkscape.org, everything? not sure, because site search uses google and at this moment shows no results if I look up for "filters". If I search for "filters" there are no Page title matches If I search for "effects" the second one in Page title is "filter effects", that is not how a search engine in 2010 works and Dokuwiki search is more intelligent than this.

Search on the main site is bad, but I wasn't saying the main site is not broken. The main site desperately does need an overhaul and I'm eagerly awaiting the new main site :). But wiki is another matter. Search on the wiki is bad as well, because it uses the very basic built-in search. Installing this would help; it is what Wikipedia uses. http://www.mediawiki.org/wiki/Extension:MWSearch

As someone says in this thread, there is a good momentum (meaning willing people) to create a nice community and documentation website for Inkscape. Some of us are not C++ coders so we will be pretty happy with python-django-js/html/css-sql migrating helping.

This is very good. I just don't want you to waste your momentum on something that won't improve the situation. In the past I have attempted a few projects that proved to be too large for a single person to complete, and rewriting every wiki page looks like it. In the end though, as Jasper said, we can't stop you.

Regards, Krzysztof

2010/12/19 Krzysztof Kosiński <tweenk.pl@...400...>:

To sum up my points:

1. Don't try to fix things that work very well.
2. Standing on the shoulders of giants is good.
3. Fix the main site first.

I agree wholeheartedly.

On Fri, Dec 17, 2010 at 5:03 PM, Jasper van de Gronde wrote:

So why not simply move most of our site over to the wiki?

Scribus is moving to mediawiki actually. And I don't mind telling you that the thought of managing news and setting a dedicated RSS for news alone drives me nuts. I don't even mention archiving of news.

Alexandre Prokoudine http://libregraphicsworld.org

On 2010-12-21 17:20, Pajarico wrote:

... I will try to outline them, correct me me if I'm wrong:

1. The website is not good (missing sections, not attractive, not

descriptive enough for newbies...). 2. The wiki (read this as "the collaborative are with easy access and editing capabilities") is not good because it has: ** a) lot's of stuff that should be in the website. ** b) many articles are outdated. 3. Some people don't like wikimedia while others do.

This is partly true, but at least for me the problem isn't so much that I prefer wikimedia over some other piece of software, but rather wether it is worth the effort to move to something else. I have no doubt that pretty much any system can fulfill our basic technical needs. Nor do I doubt that there might be systems out there that do a better job at it than mediawiki (note the subtle, but crucial, difference between mediawiki and wikimedia, the former being a software package, the latter being an organization).

... The debate shouldn't be about personal choices but rather which tools are better for each problem, which in turn requires us to have a very specific understanding on what the problems really are.

True, but I think most arguments on either side have been laid on the table at one time or another already. Personally I am interested in seeing what alternatives to the current system will be proposed (and how the migration to those systems is planned). I am also still interested in participating in a coordinate effort to clean up the /content/ on the wiki, if one is set up. (I'm not volunteering to lead such an effort.)