I've been thinking about how to best and with less changes to the current website make the into-tour to Pd land feel more like trip to Bhutan; or Nangijala if you prefer.
My focus was fist to give a more detailed explanation of what opportunities there are with respect to getting Pd. The fist easy step was to add extra information to the downloads section (and maybe rename it to "getting Pd"), but i've fund that it might be better to do some more through out chances to the site, which i think will be a good solution in the long run.
To be more precise. Instead of expanding the download page, i'd keep it simple but serve the info i think is needed (or would be nice to have) elsewhere:
The About section, which i'd like to expand into three parts. 1) a slight rewrite of the current about page making it more like the wikipedia page on Pd, that is with a few screenshots and feature descriptions. 2) some explicit examples that can be downloaded, much like the examples on the processing site. This have been discussed before, where the conclusion more or less were, that having both a curated showroom regularly updated and a more alive share-your-work-section on the website would be more desirable then a static example section just. I still agree. But i'd rather have a static example section then nothing. And it seam more likely that such think cold happen then the other. And then it will be more in line with this About section, it could use more digestible examples, which would let fx a showroom use it's potential to have a more advanced and arty focus. 3) a page describing the goods in the Pd shop (vanilla, pd- extended, devel, externals, abstractions, pddp, etc). This section in particular i think new users would benefit from knowing from the start. i wish i did.
The documentation section. There will be pointers from that about section 3) to appropriate pages or parts of the documentation section. Fx. about how to build Pd or externals one self. I think it would be nice to have a sub-section of the documentation dedicated to building. That is move the general building stuff out of the dev section and into the user docs.
Another sub-section i think would be nice to have in the docs section, which also relates very much to new users, has to do with the ideas Georg roughly expressed in on pd-list about adding info about how to load lib in Pd-extended, namely a section about the fist steps one would do in the Pd world just after reading the About section, having installed it and read the (html) manual. Issues like - how is the help browser organized - how do i use other peoples patches, which is much related to - loading libs or abstractions, or starting Pd In other word a more pragmatic intro then then one from the manual (syntax) and the interactive getting started with the Pd (semantic) (and the about section ("what it this at all"?))
I'll stop this here. What i think should be reorganized elsewhere - in particular in the docs section - i won't bother you with now.
It would be nice to know what you folks think about these ideas. Fx. how does this fit with what the you'd like to see happen?
This is great! I think that 'silk gloves' are exactly what is needed. I mean, I've been using Pd for a while now, and I couldn't even figure out the whole [libdir] thing in Pd extended.
This is a perfect approach.
~Kyle
On 1/28/07, Steffen stffn@dibidut.dk wrote:
I've been thinking about how to best and with less changes to the current website make the into-tour to Pd land feel more like trip to Bhutan; or Nangijala if you prefer.
My focus was fist to give a more detailed explanation of what opportunities there are with respect to getting Pd. The fist easy step was to add extra information to the downloads section (and maybe rename it to "getting Pd"), but i've fund that it might be better to do some more through out chances to the site, which i think will be a good solution in the long run.
To be more precise. Instead of expanding the download page, i'd keep it simple but serve the info i think is needed (or would be nice to have) elsewhere:
The About section, which i'd like to expand into three parts.
- a slight rewrite of the current about page making it more like the
wikipedia page on Pd, that is with a few screenshots and feature descriptions. 2) some explicit examples that can be downloaded, much like the examples on the processing site. This have been discussed before, where the conclusion more or less were, that having both a curated showroom regularly updated and a more alive share-your-work-section on the website would be more desirable then a static example section just. I still agree. But i'd rather have a static example section then nothing. And it seam more likely that such think cold happen then the other. And then it will be more in line with this About section, it could use more digestible examples, which would let fx a showroom use it's potential to have a more advanced and arty focus. 3) a page describing the goods in the Pd shop (vanilla, pd- extended, devel, externals, abstractions, pddp, etc). This section in particular i think new users would benefit from knowing from the start. i wish i did.
The documentation section. There will be pointers from that about section 3) to appropriate pages or parts of the documentation section. Fx. about how to build Pd or externals one self. I think it would be nice to have a sub-section of the documentation dedicated to building. That is move the general building stuff out of the dev section and into the user docs.
Another sub-section i think would be nice to have in the docs section, which also relates very much to new users, has to do with the ideas Georg roughly expressed in on pd-list about adding info about how to load lib in Pd-extended, namely a section about the fist steps one would do in the Pd world just after reading the About section, having installed it and read the (html) manual. Issues like
- how is the help browser organized
- how do i use other peoples patches, which is much related to
- loading libs or abstractions, or starting Pd
In other word a more pragmatic intro then then one from the manual (syntax) and the interactive getting started with the Pd (semantic) (and the about section ("what it this at all"?))
I'll stop this here. What i think should be reorganized elsewhere - in particular in the docs section - i won't bother you with now.
It would be nice to know what you folks think about these ideas. Fx. how does this fit with what the you'd like to see happen?
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
Hallo Steffen!
The About section, which i'd like to expand into three parts.
[...]
- a page describing the goods in the Pd shop (vanilla, pd-extended,
devel, externals, abstractions, pddp, etc). This section in particular i think new users would benefit from knowing from the start. i wish i did.
yes, I think this should go into the documentation section - and also linked from the download section or something like that - so that you know what you want to download and how to use it ...
(okay, you said something similar too ... ;)
It would be nice to know what you folks think about these ideas. Fx. how does this fit with what the you'd like to see happen?
Very nice - I think this is very important! I will also try to help with the documentation for libdir and etc. when I get it running ... ;)
@IOhannes: Is it possible to set the rights in these sections, so that we can modify puredata.org like this ?
Or maybe as a general question, is it good to let all registered people edit these pages ?
LG Georg
Georg Holzmann wrote:
Hallo Steffen!
@IOhannes: Is it possible to set the rights in these sections, so that we can modify puredata.org like this ?
Or maybe as a general question, is it good to let all registered people edit these pages ?
right, we should find a consensus about this before i open the page.
ideas: 1) totally open page: everybody registered can write (add/modify/delete) everything everywhere, including the private section of the members 2) open page: everybody registered can write (a/m/d) in all sections BUT the members folders. 3) closed page: only "certain" members can edit the non-members areas
i personally favour #3 (#1 being a bit risky; for #2 i'd have to invest administrative thinking, which i'd rather not) HOWEVER: (in #3) most of the sections like ./doc ./dev and the like should really become collections of stuff that is spread over the site (like the /community/patches), so people can really contribute without too much bureaucracy....
anyhow, whichever security model is chosen, it should be discussed here.
mfga.sdr. IOhannes
First of all, thanks for the response! It really is much appreciated.
On 30/01/2007, at 9.14, IOhannes m zmoelnig wrote:
Georg Holzmann wrote:
Hallo Steffen!
@IOhannes: Is it possible to set the rights in these sections, so that we can modify puredata.org like this ?
Or maybe as a general question, is it good to let all registered people edit these pages ?
right, we should find a consensus about this before i open the page.
ideas:
- totally open page: everybody registered can write (add/modify/
delete) everything everywhere, including the private section of the members 2) open page: everybody registered can write (a/m/d) in all sections BUT the members folders. 3) closed page: only "certain" members can edit the non-members areas
I also prefer 3), but with a few trivial extensions. As i see it, the site is now divided into tree parts: a) the members pages, b) the wiki pages and c) the non-wiki pages, where b) and c) are non-members pages. Hence the wee extension would be:
4) semi closed page: only "certain" members can edit the non-members non-wiki areas (that is c)). Any member can edit the wiki pages (that is b)). Only the member can edit there own member area, except a super user incase of for example child porn.
To make it consistent with how the CVS repo works, people would then have to apply to be one of those "certain" members, that can edit the non-wiki pages.
And there need to be decided what should be wiki and what should be non-wiki. For example could the community section be a wiki, while anything else could be non-wiki?
anyhow, whichever security model is chosen, it should be discussed here.
Agreed indeed. For example i'd like to know what Hans thinks about this, as he mentioned earlier that he had some strong opinions on what should happen to dev/ and docs/.
Hallo!
ideas:
- totally open page: everybody registered can write (add/modify/delete)
everything everywhere, including the private section of the members 2) open page: everybody registered can write (a/m/d) in all sections BUT the members folders. 3) closed page: only "certain" members can edit the non-members areas
I also prefer 3), but with a few trivial extensions. As i see it, the site is now divided into tree parts: a) the members pages, b) the wiki pages and c) the non-wiki pages, where b) and c) are non-members pages. Hence the wee extension would be:
I am for 2 - I think it's the easiest way, so we don't need more special extensions and whatever ...
To make it consistent with how the CVS repo works, people would then have to apply to be one of those "certain" members, that can edit the non-wiki pages.
But I think this border to apply is too complicated - e.g. I have some time today at night and I am not registered and want to write a small addition to the page - then I don't wait until I'm registered and then maybe in a week I will continue ... I don't do it !
(I think it's different with the code in cvs ...)
Why should this be too open ? - If we see that there are problems we can undo the change ...
LG Georg
On 30/01/2007, at 18.52, Georg Holzmann wrote:
But I think this border to apply is too complicated - e.g. I have some time today at night and I am not registered and want to write a small addition to the page - then I don't wait until I'm registered and then maybe in a week I will continue ... I don't do it !
(I think it's different with the code in cvs ...)
Why should this be too open ? - If we see that there are problems we can undo the change ...
I see your point. I'm not sure what i think right now.
hi, can I join the discussion? I think the front page and main pages should only be editable by webadmins. members should be able to edit their own page. the rest could be the open section (wiki like). esp. documentation, forums, groups, concerts, links should be open for all registered users. plus again my proposal for a youtube like upload section for videos (+ autoconvert module for movie, avi, mp4), sounds (mp3, ogg), pictures, patches, abstractions, externals, settings for patches (like sequencer files). including free tagging/labeling. I learned about drupal and think, it would be an alternative or possible addition to plone. marius.
Georg Holzmann wrote:
Hallo!
ideas:
- totally open page: everybody registered can write (add/modify/delete)
everything everywhere, including the private section of the members 2) open page: everybody registered can write (a/m/d) in all sections BUT the members folders. 3) closed page: only "certain" members can edit the non-members areas
I also prefer 3), but with a few trivial extensions. As i see it, the site is now divided into tree parts: a) the members pages, b) the wiki pages and c) the non-wiki pages, where b) and c) are non-members pages. Hence the wee extension would be:
I am for 2 - I think it's the easiest way, so we don't need more special extensions and whatever ...
To make it consistent with how the CVS repo works, people would then have to apply to be one of those "certain" members, that can edit the non-wiki pages.
But I think this border to apply is too complicated - e.g. I have some time today at night and I am not registered and want to write a small addition to the page - then I don't wait until I'm registered and then maybe in a week I will continue ... I don't do it !
(I think it's different with the code in cvs ...)
Why should this be too open ? - If we see that there are problems we can undo the change ...
LG Georg
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
marius schebella wrote:
hi, can I join the discussion? I think the front page and main pages should only be editable by webadmins. members should be able to edit their own page. the rest could be the open section (wiki like). esp. documentation, forums, groups, concerts, links should be open for all registered users. plus again my proposal for a youtube like upload section for videos (+ autoconvert module for movie, avi, mp4), sounds (mp3, ogg), pictures, patches, abstractions, externals, settings for patches (like sequencer files). including free tagging/labeling.
i don't think we (the iem) can offer the ressources for a "youtube like upload section" (but i might be wrong). the usual way this is handled by externalizing the resource-hogs (put movies on youtube, put images on flickr, put installers on sourceforge - and reference from your site to this content)
mfg.a IOhannes
I learned about drupal and think, it would be an alternative or possible addition to plone.
to acchieve what exactly? (i'm just curious)
mf.adsr IOhannes
marius.
On Jan 30, 2007, at 8:53 AM, Steffen wrote:
First of all, thanks for the response! It really is much appreciated.
On 30/01/2007, at 9.14, IOhannes m zmoelnig wrote:
Georg Holzmann wrote:
Hallo Steffen!
@IOhannes: Is it possible to set the rights in these sections, so that we can modify puredata.org like this ?
Or maybe as a general question, is it good to let all registered people edit these pages ?
right, we should find a consensus about this before i open the page.
ideas:
- totally open page: everybody registered can write (add/modify/
delete) everything everywhere, including the private section of the members 2) open page: everybody registered can write (a/m/d) in all sections BUT the members folders. 3) closed page: only "certain" members can edit the non-members areas
I also prefer 3), but with a few trivial extensions. As i see it, the site is now divided into tree parts: a) the members pages, b) the wiki pages and c) the non-wiki pages, where b) and c) are non- members pages. Hence the wee extension would be:
- semi closed page: only "certain" members can edit the non-
members non-wiki areas (that is c)). Any member can edit the wiki pages (that is b)). Only the member can edit there own member area, except a super user incase of for example child porn.
To make it consistent with how the CVS repo works, people would then have to apply to be one of those "certain" members, that can edit the non-wiki pages.
And there need to be decided what should be wiki and what should be non-wiki. For example could the community section be a wiki, while anything else could be non-wiki?
anyhow, whichever security model is chosen, it should be discussed here.
Agreed indeed. For example i'd like to know what Hans thinks about this, as he mentioned earlier that he had some strong opinions on what should happen to dev/ and docs/.
I think these should be wikis basically, we should lay out the structure, but let anyone edit. Then we just need to agree on the structure and have a few wikipedians to keep it organized that way. I am willing to be one of those wikipedians.
.hc
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
On 02/02/2007, at 2.55, Hans-Christoph Steiner wrote:
I think these should be wikis basically, we should lay out the structure, but let anyone edit. Then we just need to agree on the structure and have a few wikipedians to keep it organized that way. I am willing to be one of those wikipedians.
I'm also now more into solution 2).
Regarding agreeing on structure. I think it's very important to do that, as it is for content. Hence i think useing this list as a discussing platform for changes to the site is good. That means that people should really take the time to post to the list about changes they make to let anyone know about it. Or if it is more radical changes propose the idea for discussion first. That would make the developing and maintaining of the site more democratic and open. To me that is more important then how and who can edit the site.
On Jan 30, 2007, at 3:14 AM, IOhannes m zmoelnig wrote:
Georg Holzmann wrote:
Hallo Steffen!
@IOhannes: Is it possible to set the rights in these sections, so that we can modify puredata.org like this ?
Or maybe as a general question, is it good to let all registered people edit these pages ?
right, we should find a consensus about this before i open the page.
ideas:
- totally open page: everybody registered can write (add/modify/
delete) everything everywhere, including the private section of the members 2) open page: everybody registered can write (a/m/d) in all sections BUT the members folders.
I vote 2 if it is not too much work. Then we just need some wikipedians to keep things reasonably clean.
.hc
- closed page: only "certain" members can edit the non-members areas
i personally favour #3 (#1 being a bit risky; for #2 i'd have to invest administrative thinking, which i'd rather not) HOWEVER: (in #3) most of the sections like ./doc ./dev and the like should really become collections of stuff that is spread over the site (like the /community/patches), so people can really contribute without too much bureaucracy....
anyhow, whichever security model is chosen, it should be discussed here.
mfga.sdr. IOhannes
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
On Jan 28, 2007, at 5:40 PM, Steffen wrote:
I've been thinking about how to best and with less changes to the current website make the into-tour to Pd land feel more like trip to Bhutan; or Nangijala if you prefer.
My focus was fist to give a more detailed explanation of what opportunities there are with respect to getting Pd. The fist easy step was to add extra information to the downloads section (and maybe rename it to "getting Pd"), but i've fund that it might be better to do some more through out chances to the site, which i think will be a good solution in the long run.
I think "downloads" is appropriate since most software pages use that term for the page where you get the software, from my experience.
To be more precise. Instead of expanding the download page, i'd keep it simple but serve the info i think is needed (or would be nice to have) elsewhere:
The About section, which i'd like to expand into three parts.
- a slight rewrite of the current about page making it more like
the wikipedia page on Pd, that is with a few screenshots and feature descriptions.
yes!
- some explicit examples that can be downloaded, much like the
examples on the processing site. This have been discussed before, where the conclusion more or less were, that having both a curated showroom regularly updated and a more alive share-your-work-section on the website would be more desirable then a static example section just. I still agree. But i'd rather have a static example section then nothing. And it seam more likely that such think cold happen then the other. And then it will be more in line with this About section, it could use more digestible examples, which would let fx a showroom use it's potential to have a more advanced and arty focus.
I think this should be the showroom. We should strongly encourage people to include the sources. It could also be a question for the curator at the time. If I was curating, I think I would only include works that release at least some of the sources.
- a page describing the goods in the Pd shop (vanilla, pd-
extended, devel, externals, abstractions, pddp, etc). This section in particular i think new users would benefit from knowing from the start. i wish i did.
I don't think newbies need to know about the subsections "externals", "abstractions", "pddp", etc. But yes to the vanilla/pd-extended/ devel discussion. I tried to explain on the downloads page, but I suppose it could be made clearer.
The documentation section. There will be pointers from that about section 3) to appropriate pages or parts of the documentation section. Fx. about how to build Pd or externals one self. I think it would be nice to have a sub-section of the documentation dedicated to building. That is move the general building stuff out of the dev section and into the user docs.
"user docs" should be newbie focused, but build stuff could go in an "advanced" section I suppose. But generally, building software is categorized as "developer" stuff, from my experience. To me, it is very important that we do not needlessly create our own categories for these things. There is a pretty broad consensus for how to label and categorize these things on websites which I think we should follow.
Another sub-section i think would be nice to have in the docs section, which also relates very much to new users, has to do with the ideas Georg roughly expressed in on pd-list about adding info about how to load lib in Pd-extended, namely a section about the fist steps one would do in the Pd world just after reading the About section, having installed it and read the (html) manual. Issues like
- how is the help browser organized
- how do i use other peoples patches, which is much related to
- loading libs or abstractions, or starting Pd
In other word a more pragmatic intro then then one from the manual (syntax) and the interactive getting started with the Pd (semantic) (and the about section ("what it this at all"?))
Sounds good, sounds like specific user docs.
.hc
I'll stop this here. What i think should be reorganized elsewhere - in particular in the docs section - i won't bother you with now.
It would be nice to know what you folks think about these ideas. Fx. how does this fit with what the you'd like to see happen?
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
On 02/02/2007, at 2.48, Hans-Christoph Steiner wrote:
On Jan 28, 2007, at 5:40 PM, Steffen wrote:
I've been thinking about how to best and with less changes to the current website make the into-tour to Pd land feel more like trip to Bhutan; or Nangijala if you prefer.
My focus was fist to give a more detailed explanation of what opportunities there are with respect to getting Pd. The fist easy step was to add extra information to the downloads section (and maybe rename it to "getting Pd"), but i've fund that it might be better to do some more through out chances to the site, which i think will be a good solution in the long run.
I think "downloads" is appropriate since most software pages use that term for the page where you get the software, from my experience.
Ok. Gentoo, fx, uses 'get gentoo'. But the reason for changing it wasn't that, as mush as it was to hint more insight. It can be "downloads" for me, it not the end of the world.
- some explicit examples that can be downloaded, much like the
examples on the processing site. This have been discussed before, where the conclusion more or less were, that having both a curated showroom regularly updated and a more alive share-your-work- section on the website would be more desirable then a static example section just. I still agree. But i'd rather have a static example section then nothing. And it seam more likely that such think cold happen then the other. And then it will be more in line with this About section, it could use more digestible examples, which would let fx a showroom use it's potential to have a more advanced and arty focus.
I think this should be the showroom. We should strongly encourage people to include the sources. It could also be a question for the curator at the time. If I was curating, I think I would only include works that release at least some of the sources.
I'd like such showroom too. But a section with easy examples related to the About page i think would be a good start. It could be seen as redundant given the material in the help browser, but displaying a few easy things in a webpage i think will fertilizes downloading Pd in the fist place. Again, it's not the end of the world, and if there at some point will be a showroom, the examples section could just end with a pointer to that showroom for more material.
- a page describing the goods in the Pd shop (vanilla, pd-
extended, devel, externals, abstractions, pddp, etc). This section in particular i think new users would benefit from knowing from the start. i wish i did.
I don't think newbies need to know about the subsections "externals", "abstractions", "pddp", etc. But yes to the vanilla/ pd-extended/devel discussion. I tried to explain on the downloads page, but I suppose it could be made clearer.
My newbie experience is that i wanted to know about these thinks before i started patching. I don't think it should be the fist thing displayed, but there are users to whom it matters how things could put together - or how things are organized. As for abstractions, i think even more new'ish users like to know about it.
The documentation section. There will be pointers from that about section 3) to appropriate pages or parts of the documentation section. Fx. about how to build Pd or externals one self. I think it would be nice to have a sub-section of the documentation dedicated to building. That is move the general building stuff out of the dev section and into the user docs.
"user docs" should be newbie focused, but build stuff could go in an "advanced" section I suppose. But generally, building software is categorized as "developer" stuff, from my experience. To me, it is very important that we do not needlessly create our own categories for these things. There is a pretty broad consensus for how to label and categorize these things on websites which I think we should follow.
Ok. I don't want to create new categories. It's not that. It's just that in this particular situation the line between building as a user and building as a developer is thin. It does makes sense to build stuff as a user, as it does makes sense to bug report as a user. I might be off the bat. Anyways, it's not the end of the world to me where the info is placed.
Hallo!
I want to reactivate this discussion, so that it wasn't for nothing ... ;)
So on what did we decide now? Can we at least open the community folder for members ? (well, I would be for all puredata.org but not the main page)
Then the members would have write privilegs in their home and community folder.
LG Georg
I've been thinking about how to best and with less changes to the current website make the into-tour to Pd land feel more like trip to Bhutan; or Nangijala if you prefer.
My focus was fist to give a more detailed explanation of what opportunities there are with respect to getting Pd. The fist easy step was to add extra information to the downloads section (and maybe rename it to "getting Pd"), but i've fund that it might be better to do some more through out chances to the site, which i think will be a good solution in the long run.
I think "downloads" is appropriate since most software pages use that term for the page where you get the software, from my experience.
Ok. Gentoo, fx, uses 'get gentoo'. But the reason for changing it wasn't that, as mush as it was to hint more insight. It can be "downloads" for me, it not the end of the world.
- some explicit examples that can be downloaded, much like the
examples on the processing site. This have been discussed before, where the conclusion more or less were, that having both a curated showroom regularly updated and a more alive share-your-work-section on the website would be more desirable then a static example section just. I still agree. But i'd rather have a static example section then nothing. And it seam more likely that such think cold happen then the other. And then it will be more in line with this About section, it could use more digestible examples, which would let fx a showroom use it's potential to have a more advanced and arty focus.
I think this should be the showroom. We should strongly encourage people to include the sources. It could also be a question for the curator at the time. If I was curating, I think I would only include works that release at least some of the sources.
I'd like such showroom too. But a section with easy examples related to the About page i think would be a good start. It could be seen as redundant given the material in the help browser, but displaying a few easy things in a webpage i think will fertilizes downloading Pd in the fist place. Again, it's not the end of the world, and if there at some point will be a showroom, the examples section could just end with a pointer to that showroom for more material.
- a page describing the goods in the Pd shop (vanilla, pd-extended,
devel, externals, abstractions, pddp, etc). This section in particular i think new users would benefit from knowing from the start. i wish i did.
I don't think newbies need to know about the subsections "externals", "abstractions", "pddp", etc. But yes to the vanilla/pd-extended/devel discussion. I tried to explain on the downloads page, but I suppose it could be made clearer.
My newbie experience is that i wanted to know about these thinks before i started patching. I don't think it should be the fist thing displayed, but there are users to whom it matters how things could put together - or how things are organized. As for abstractions, i think even more new'ish users like to know about it.
The documentation section. There will be pointers from that about section 3) to appropriate pages or parts of the documentation section. Fx. about how to build Pd or externals one self. I think it would be nice to have a sub-section of the documentation dedicated to building. That is move the general building stuff out of the dev section and into the user docs.
"user docs" should be newbie focused, but build stuff could go in an "advanced" section I suppose. But generally, building software is categorized as "developer" stuff, from my experience. To me, it is very important that we do not needlessly create our own categories for these things. There is a pretty broad consensus for how to label and categorize these things on websites which I think we should follow.
Ok. I don't want to create new categories. It's not that. It's just that in this particular situation the line between building as a user and building as a developer is thin. It does makes sense to build stuff as a user, as it does makes sense to bug report as a user. I might be off the bat. Anyways, it's not the end of the world to me where the info is placed.
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
what if you only have write permissions to your local folder, but every new post will also show up on the front page or let's say the front page of the forum with a link to your homefolder and possibility to comment the article. marius.
Georg Holzmann wrote:
Hallo!
I want to reactivate this discussion, so that it wasn't for nothing ... ;)
So on what did we decide now? Can we at least open the community folder for members ? (well, I would be for all puredata.org but not the main page)
Then the members would have write privilegs in their home and community folder.
LG Georg
I've been thinking about how to best and with less changes to the current website make the into-tour to Pd land feel more like trip to Bhutan; or Nangijala if you prefer.
My focus was fist to give a more detailed explanation of what opportunities there are with respect to getting Pd. The fist easy step was to add extra information to the downloads section (and maybe rename it to "getting Pd"), but i've fund that it might be better to do some more through out chances to the site, which i think will be a good solution in the long run.
I think "downloads" is appropriate since most software pages use that term for the page where you get the software, from my experience.
Ok. Gentoo, fx, uses 'get gentoo'. But the reason for changing it wasn't that, as mush as it was to hint more insight. It can be "downloads" for me, it not the end of the world.
- some explicit examples that can be downloaded, much like the
examples on the processing site. This have been discussed before, where the conclusion more or less were, that having both a curated showroom regularly updated and a more alive share-your-work-section on the website would be more desirable then a static example section just. I still agree. But i'd rather have a static example section then nothing. And it seam more likely that such think cold happen then the other. And then it will be more in line with this About section, it could use more digestible examples, which would let fx a showroom use it's potential to have a more advanced and arty focus.
I think this should be the showroom. We should strongly encourage people to include the sources. It could also be a question for the curator at the time. If I was curating, I think I would only include works that release at least some of the sources.
I'd like such showroom too. But a section with easy examples related to the About page i think would be a good start. It could be seen as redundant given the material in the help browser, but displaying a few easy things in a webpage i think will fertilizes downloading Pd in the fist place. Again, it's not the end of the world, and if there at some point will be a showroom, the examples section could just end with a pointer to that showroom for more material.
- a page describing the goods in the Pd shop (vanilla, pd-extended,
devel, externals, abstractions, pddp, etc). This section in particular i think new users would benefit from knowing from the start. i wish i did.
I don't think newbies need to know about the subsections "externals", "abstractions", "pddp", etc. But yes to the vanilla/pd-extended/devel discussion. I tried to explain on the downloads page, but I suppose it could be made clearer.
My newbie experience is that i wanted to know about these thinks before i started patching. I don't think it should be the fist thing displayed, but there are users to whom it matters how things could put together - or how things are organized. As for abstractions, i think even more new'ish users like to know about it.
The documentation section. There will be pointers from that about section 3) to appropriate pages or parts of the documentation section. Fx. about how to build Pd or externals one self. I think it would be nice to have a sub-section of the documentation dedicated to building. That is move the general building stuff out of the dev section and into the user docs.
"user docs" should be newbie focused, but build stuff could go in an "advanced" section I suppose. But generally, building software is categorized as "developer" stuff, from my experience. To me, it is very important that we do not needlessly create our own categories for these things. There is a pretty broad consensus for how to label and categorize these things on websites which I think we should follow.
Ok. I don't want to create new categories. It's not that. It's just that in this particular situation the line between building as a user and building as a developer is thin. It does makes sense to build stuff as a user, as it does makes sense to bug report as a user. I might be off the bat. Anyways, it's not the end of the world to me where the info is placed.
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
Hallo!
what if you only have write permissions to your local folder, but every new post will also show up on the front page or let's say the front page of the forum with a link to your homefolder and possibility to comment the article.
Wow - this is now too complicated for me ... :)
What do you mean with "your local folder" ? The members home folder ? Then it's like now (excpet the post of the front page) and then I think we will discourage people from making content, restructuring a page ...
E.g. I just tried to make a page for project-ideas for google summer of code and have no rights for it - and I don't think that this should go into my member folder ...
LG Georg
I am working with a cms called drupal, and when I want to post new content I can check a box, if I want to have a teaser appear on the frontpage or not. or whether I want to have guest comments. I think there are similar possibilities for plone, so I was suggesting that people register and then they can post new pages, files... marius.
Georg Holzmann wrote:
Hallo!
what if you only have write permissions to your local folder, but every new post will also show up on the front page or let's say the front page of the forum with a link to your homefolder and possibility to comment the article.
Wow - this is now too complicated for me ... :)
What do you mean with "your local folder" ? The members home folder ? Then it's like now (excpet the post of the front page) and then I think we will discourage people from making content, restructuring a page ...
E.g. I just tried to make a page for project-ideas for google summer of code and have no rights for it - and I don't think that this should go into my member folder ...
LG Georg
Hallo, marius schebella hat gesagt: // marius schebella wrote:
I am working with a cms called drupal, and when I want to post new content I can check a box, if I want to have a teaser appear on the frontpage or not. or whether I want to have guest comments. I think there are similar possibilities for plone, so I was suggesting that people register and then they can post new pages, files...
This is not only possible but actually the way, that "News" items appear in the right column of the main page, IIRC. You just add a special type "News Item" or so and you're set.
Caio
oh, did not know that, well then that is it, have nothing to add... marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
I am working with a cms called drupal, and when I want to post new content I can check a box, if I want to have a teaser appear on the frontpage or not. or whether I want to have guest comments. I think there are similar possibilities for plone, so I was suggesting that people register and then they can post new pages, files...
This is not only possible but actually the way, that "News" items appear in the right column of the main page, IIRC. You just add a special type "News Item" or so and you're set.
Caio
I'd like to see the site simplified, and have a curated exhibition section.
.hc
On Feb 26, 2007, at 1:13 PM, Georg Holzmann wrote:
Hallo!
I want to reactivate this discussion, so that it wasn't for nothing ... ;)
So on what did we decide now? Can we at least open the community folder for members ? (well, I would be for all puredata.org but not the main page)
Then the members would have write privilegs in their home and community folder.
LG Georg
I've been thinking about how to best and with less changes to the current website make the into-tour to Pd land feel more like trip to Bhutan; or Nangijala if you prefer.
My focus was fist to give a more detailed explanation of what opportunities there are with respect to getting Pd. The fist easy step was to add extra information to the downloads section (and maybe rename it to "getting Pd"), but i've fund that it might be better to do some more through out chances to the site, which i think will be a good solution in the long run.
I think "downloads" is appropriate since most software pages use that term for the page where you get the software, from my experience.
Ok. Gentoo, fx, uses 'get gentoo'. But the reason for changing it wasn't that, as mush as it was to hint more insight. It can be "downloads" for me, it not the end of the world.
- some explicit examples that can be downloaded, much like the
examples on the processing site. This have been discussed before, where the conclusion more or less were, that having both a curated showroom regularly updated and a more alive share-your- work-section on the website would be more desirable then a static example section just. I still agree. But i'd rather have a static example section then nothing. And it seam more likely that such think cold happen then the other. And then it will be more in line with this About section, it could use more digestible examples, which would let fx a showroom use it's potential to have a more advanced and arty focus.
I think this should be the showroom. We should strongly encourage people to include the sources. It could also be a question for the curator at the time. If I was curating, I think I would only include works that release at least some of the sources.
I'd like such showroom too. But a section with easy examples related to the About page i think would be a good start. It could be seen as redundant given the material in the help browser, but displaying a few easy things in a webpage i think will fertilizes downloading Pd in the fist place. Again, it's not the end of the world, and if there at some point will be a showroom, the examples section could just end with a pointer to that showroom for more material.
- a page describing the goods in the Pd shop (vanilla, pd-
extended, devel, externals, abstractions, pddp, etc). This section in particular i think new users would benefit from knowing from the start. i wish i did.
I don't think newbies need to know about the subsections "externals", "abstractions", "pddp", etc. But yes to the vanilla/ pd-extended/devel discussion. I tried to explain on the downloads page, but I suppose it could be made clearer.
My newbie experience is that i wanted to know about these thinks before i started patching. I don't think it should be the fist thing displayed, but there are users to whom it matters how things could put together - or how things are organized. As for abstractions, i think even more new'ish users like to know about it.
The documentation section. There will be pointers from that about section 3) to appropriate pages or parts of the documentation section. Fx. about how to build Pd or externals one self. I think it would be nice to have a sub-section of the documentation dedicated to building. That is move the general building stuff out of the dev section and into the user docs.
"user docs" should be newbie focused, but build stuff could go in an "advanced" section I suppose. But generally, building software is categorized as "developer" stuff, from my experience. To me, it is very important that we do not needlessly create our own categories for these things. There is a pretty broad consensus for how to label and categorize these things on websites which I think we should follow.
Ok. I don't want to create new categories. It's not that. It's just that in this particular situation the line between building as a user and building as a developer is thin. It does makes sense to build stuff as a user, as it does makes sense to bug report as a user. I might be off the bat. Anyways, it's not the end of the world to me where the info is placed. _______________________________________________ pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On 28/02/2007, at 6.23, Hans-Christoph Steiner wrote:
I'd like to see the site simplified,
IOhannes wrote:
"we should find a consensus about this before i open the page."
And this consensus haven't happened, so i guess it's hard to do much about it as is. It might be possible to write up suggestions in ones user area first, then ask if it's ok, and then it can get into the intended place on the site by someone with the sufficient write privileges?
and have a curated exhibition section.
If someone with sufficient privileges will set up a folder for it, where i/we can add wiki pages i'd give it a push. It could be / exhibition or /showroom or /gallery or slash-something-else. I'm not picky. It could also be in /community/projects, but i think thats hiding it away too much.
In that folder, i'd create - a wiki page ./about with some general info about what the exhibition/showroom/gallery is about. - a wiki page ./organization or something like wise to use for organizing it. Describing the procedure, what information and meta information there need be in each "issue"/"volume"/exhibition and organizing who'll curate when. - a wiki page ./archive with links to the past exhibitions.
Then all exhibitions, if i can decide, will have a wiki page each, named ./vol<number> or ./issue<number>. I think doing it this way is better then being monthly or bi-monthly, since then it can be sometimes monthly and some times bi-monthly - or what ever - without looking silly.
Apropos duration. I don't think an exhibition should laster less then a month. It's not to make it dull, but to give time to something serious to emerge. Separating it from the casual blog-sphere. In other words to give the curators time to make something interesting out of it, to increase quality!
The, say, /exhibition will point to the latest exhibition.
It would be good if a coming curator could be able to plan ahead and start making the wiki page before it goes "on air", hence some management in that direction would be needed. I don't know if one can just manually set the ./exhibition thing to point to a given wiki page, that might be the easiest way to realize both the archive, the pointer to the current exhibition and give coming curators the possibility to plan ahead. This also mean that the dir-listing that happens in the menu should be turned off for this folder or at least that future/planed exhibitions should be invisible.
When it's set up and ready for action i could send a few PR emails. For example to Create Digital Music, .microsound-announce, Pd- announce and what have we. From then it could be organized though the wiki and this list.
What do you all think? How would curate? Can write access to a place like that be given?
On Feb 28, 2007, at 5:55 PM, Steffen wrote:
On 28/02/2007, at 6.23, Hans-Christoph Steiner wrote:
I'd like to see the site simplified,
IOhannes wrote:
"we should find a consensus about this before i open the page."
And this consensus haven't happened, so i guess it's hard to do much about it as is. It might be possible to write up suggestions in ones user area first, then ask if it's ok, and then it can get into the intended place on the site by someone with the sufficient write privileges?
Well, we generally work by lazy consensus, meaning post a proposal, wait a week, if there are no objections, it's approved.
and have a curated exhibition section.
If someone with sufficient privileges will set up a folder for it, where i/we can add wiki pages i'd give it a push. It could be / exhibition or /showroom or /gallery or slash-something-else. I'm not picky. It could also be in /community/projects, but i think thats hiding it away too much.
In that folder, i'd create
- a wiki page ./about with some general info about what the
exhibition/showroom/gallery is about.
- a wiki page ./organization or something like wise to use for
organizing it. Describing the procedure, what information and meta information there need be in each "issue"/"volume"/exhibition and organizing who'll curate when.
- a wiki page ./archive with links to the past exhibitions.
Then all exhibitions, if i can decide, will have a wiki page each, named ./vol<number> or ./issue<number>. I think doing it this way is better then being monthly or bi-monthly, since then it can be sometimes monthly and some times bi-monthly - or what ever - without looking silly.
Apropos duration. I don't think an exhibition should laster less then a month. It's not to make it dull, but to give time to something serious to emerge. Separating it from the casual blog- sphere. In other words to give the curators time to make something interesting out of it, to increase quality!
The, say, /exhibition will point to the latest exhibition.
It would be good if a coming curator could be able to plan ahead and start making the wiki page before it goes "on air", hence some management in that direction would be needed. I don't know if one can just manually set the ./exhibition thing to point to a given wiki page, that might be the easiest way to realize both the archive, the pointer to the current exhibition and give coming curators the possibility to plan ahead. This also mean that the dir- listing that happens in the menu should be turned off for this folder or at least that future/planed exhibitions should be invisible.
A curator-to-be could build the wiki pages in their home folder, then they would be moved into the exhibition when the time comes.
When it's set up and ready for action i could send a few PR emails. For example to Create Digital Music, .microsound-announce, Pd- announce and what have we. From then it could be organized though the wiki and this list.
What do you all think? How would curate? Can write access to a place like that be given?
I like this proposal a lot as it is now. I'd say it's a done deal in my book. I would just take this email, maybe edit it a bit, and post it to this list as it's own distinct email with a header that highlights that it's a proposal to be accepted or rejected. Then we can wait several days, if there are no objections, do it.
I do have some minor additions:
- curators cannot post their own work - people add themselves to curator slots (wiki page or whatever) - if curator slots are filled very far in advance, we change the system then
And just to be clear, there should be one "official" overarching manager/moderator for the exhibition pages to set up the current pages, manage other questions, etc. I'll do this if no one else wants to, but it sounds like you are on it, Steffen.
This sounds very good, it's about time we did this!
.hc
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
The hard part will be finding someone with the time and energy to be a curator!
~Kyle
On 2/28/07, Hans-Christoph Steiner hans@eds.org wrote:
On Feb 28, 2007, at 5:55 PM, Steffen wrote:
On 28/02/2007, at 6.23, Hans-Christoph Steiner wrote:
I'd like to see the site simplified,
IOhannes wrote:
"we should find a consensus about this before i open the page."
And this consensus haven't happened, so i guess it's hard to do much about it as is. It might be possible to write up suggestions in ones user area first, then ask if it's ok, and then it can get into the intended place on the site by someone with the sufficient write privileges?
Well, we generally work by lazy consensus, meaning post a proposal, wait a week, if there are no objections, it's approved.
and have a curated exhibition section.
If someone with sufficient privileges will set up a folder for it, where i/we can add wiki pages i'd give it a push. It could be / exhibition or /showroom or /gallery or slash-something-else. I'm not picky. It could also be in /community/projects, but i think thats hiding it away too much.
In that folder, i'd create
- a wiki page ./about with some general info about what the
exhibition/showroom/gallery is about.
- a wiki page ./organization or something like wise to use for
organizing it. Describing the procedure, what information and meta information there need be in each "issue"/"volume"/exhibition and organizing who'll curate when.
- a wiki page ./archive with links to the past exhibitions.
Then all exhibitions, if i can decide, will have a wiki page each, named ./vol<number> or ./issue<number>. I think doing it this way is better then being monthly or bi-monthly, since then it can be sometimes monthly and some times bi-monthly - or what ever - without looking silly.
Apropos duration. I don't think an exhibition should laster less then a month. It's not to make it dull, but to give time to something serious to emerge. Separating it from the casual blog- sphere. In other words to give the curators time to make something interesting out of it, to increase quality!
The, say, /exhibition will point to the latest exhibition.
It would be good if a coming curator could be able to plan ahead and start making the wiki page before it goes "on air", hence some management in that direction would be needed. I don't know if one can just manually set the ./exhibition thing to point to a given wiki page, that might be the easiest way to realize both the archive, the pointer to the current exhibition and give coming curators the possibility to plan ahead. This also mean that the dir- listing that happens in the menu should be turned off for this folder or at least that future/planed exhibitions should be invisible.
A curator-to-be could build the wiki pages in their home folder, then they would be moved into the exhibition when the time comes.
When it's set up and ready for action i could send a few PR emails. For example to Create Digital Music, .microsound-announce, Pd- announce and what have we. From then it could be organized though the wiki and this list.
What do you all think? How would curate? Can write access to a place like that be given?
I like this proposal a lot as it is now. I'd say it's a done deal in my book. I would just take this email, maybe edit it a bit, and post it to this list as it's own distinct email with a header that highlights that it's a proposal to be accepted or rejected. Then we can wait several days, if there are no objections, do it.
I do have some minor additions:
- curators cannot post their own work
- people add themselves to curator slots (wiki page or whatever)
- if curator slots are filled very far in advance, we change the
system then
And just to be clear, there should be one "official" overarching manager/moderator for the exhibition pages to set up the current pages, manage other questions, etc. I'll do this if no one else wants to, but it sounds like you are on it, Steffen.
This sounds very good, it's about time we did this!
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
Hmm, my guess is that won't be too hard. Or at least that's the hope. I'll happily do it for one month, a number of other people also expressed interest. It could be something relatively simple, or something more complicated.
Let's try it out and see what happens...
.hc
On Mar 1, 2007, at 9:45 AM, Kyle Klipowicz wrote:
The hard part will be finding someone with the time and energy to be a curator!
~Kyle
On 2/28/07, Hans-Christoph Steiner hans@eds.org wrote:
On Feb 28, 2007, at 5:55 PM, Steffen wrote:
On 28/02/2007, at 6.23, Hans-Christoph Steiner wrote:
I'd like to see the site simplified,
IOhannes wrote:
"we should find a consensus about this before i open the page."
And this consensus haven't happened, so i guess it's hard to do much about it as is. It might be possible to write up suggestions in ones user area first, then ask if it's ok, and then it can get into the intended place on the site by someone with the sufficient write privileges?
Well, we generally work by lazy consensus, meaning post a proposal, wait a week, if there are no objections, it's approved.
and have a curated exhibition section.
If someone with sufficient privileges will set up a folder for it, where i/we can add wiki pages i'd give it a push. It could be / exhibition or /showroom or /gallery or slash-something-else. I'm not picky. It could also be in /community/projects, but i think thats hiding it away too much.
In that folder, i'd create
- a wiki page ./about with some general info about what the
exhibition/showroom/gallery is about.
- a wiki page ./organization or something like wise to use for
organizing it. Describing the procedure, what information and meta information there need be in each "issue"/"volume"/exhibition and organizing who'll curate when.
- a wiki page ./archive with links to the past exhibitions.
Then all exhibitions, if i can decide, will have a wiki page each, named ./vol<number> or ./issue<number>. I think doing it this way is better then being monthly or bi-monthly, since then it can be sometimes monthly and some times bi-monthly - or what ever - without looking silly.
Apropos duration. I don't think an exhibition should laster less then a month. It's not to make it dull, but to give time to something serious to emerge. Separating it from the casual blog- sphere. In other words to give the curators time to make something interesting out of it, to increase quality!
The, say, /exhibition will point to the latest exhibition.
It would be good if a coming curator could be able to plan ahead and start making the wiki page before it goes "on air", hence some management in that direction would be needed. I don't know if one can just manually set the ./exhibition thing to point to a given wiki page, that might be the easiest way to realize both the archive, the pointer to the current exhibition and give coming curators the possibility to plan ahead. This also mean that the
dir-
listing that happens in the menu should be turned off for this folder or at least that future/planed exhibitions should be
invisible.
A curator-to-be could build the wiki pages in their home folder, then they would be moved into the exhibition when the time comes.
When it's set up and ready for action i could send a few PR emails. For example to Create Digital Music, .microsound-announce, Pd- announce and what have we. From then it could be organized though the wiki and this list.
What do you all think? How would curate? Can write access to a place like that be given?
I like this proposal a lot as it is now. I'd say it's a done deal in my book. I would just take this email, maybe edit it a bit, and post it to this list as it's own distinct email with a header that highlights that it's a proposal to be accepted or rejected. Then we can wait several days, if there are no objections, do it.
I do have some minor additions:
- curators cannot post their own work
- people add themselves to curator slots (wiki page or whatever)
- if curator slots are filled very far in advance, we change the
system then
And just to be clear, there should be one "official" overarching manager/moderator for the exhibition pages to set up the current pages, manage other questions, etc. I'll do this if no one else wants to, but it sounds like you are on it, Steffen.
This sounds very good, it's about time we did this!
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
pdweb mailing list pdweb@iem.at http://lists.puredata.info/listinfo/pdweb
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
On 01/03/2007, at 15.45, Kyle Klipowicz wrote:
The hard part will be finding someone with the time and energy to be a curator!
It's true it will take some time to be a curator. but there should be plenty of time. i mean, if each exhibition runs for more then a month, and no one takes two slots in a row...
Also, i think it would be great if we could help each other out. I'm for example not native english speaking, which means, i'm sure, that i make quite some grammatical errors. Help with proof reading would be nice. Thats just one way of we could help each other, another could way could be with developing/discussing ideas for exhibitions.
eh?
On 01/03/2007, at 3.48, Hans-Christoph Steiner wrote:
On Feb 28, 2007, at 5:55 PM, Steffen wrote:
On 28/02/2007, at 6.23, Hans-Christoph Steiner wrote:
and have a curated exhibition section.
If someone with sufficient privileges will set up a folder for it, where i/we can add wiki pages i'd give it a push. It could be / exhibition or /showroom or /gallery or slash-something-else. I'm not picky. It could also be in /community/projects, but i think thats hiding it away too much.
In that folder, i'd create
- a wiki page ./about with some general info about what the
exhibition/showroom/gallery is about.
- a wiki page ./organization or something like wise to use for
organizing it. Describing the procedure, what information and meta information there need be in each "issue"/"volume"/exhibition and organizing who'll curate when.
- a wiki page ./archive with links to the past exhibitions.
Then all exhibitions, if i can decide, will have a wiki page each, named ./vol<number> or ./issue<number>. I think doing it this way is better then being monthly or bi-monthly, since then it can be sometimes monthly and some times bi-monthly - or what ever - without looking silly.
Apropos duration. I don't think an exhibition should laster less then a month. It's not to make it dull, but to give time to something serious to emerge. Separating it from the casual blog- sphere. In other words to give the curators time to make something interesting out of it, to increase quality!
The, say, /exhibition will point to the latest exhibition.
It would be good if a coming curator could be able to plan ahead and start making the wiki page before it goes "on air", hence some management in that direction would be needed. I don't know if one can just manually set the ./exhibition thing to point to a given wiki page, that might be the easiest way to realize both the archive, the pointer to the current exhibition and give coming curators the possibility to plan ahead. This also mean that the dir-listing that happens in the menu should be turned off for this folder or at least that future/planed exhibitions should be invisible.
A curator-to-be could build the wiki pages in their home folder, then they would be moved into the exhibition when the time comes.
That could be a solution, if it's not hard to move stuff about.
Also, today i tried to make a wiki page in my home folder, but it did not work. Now it just sits there, and i can't even delete it. I tried to make a folder in my home folder, but got much like the same error as when one in general tries to make a new wiki page. Hence there are some problems as is.
When it's set up and ready for action i could send a few PR emails. For example to Create Digital Music, .microsound-announce, Pd-announce and what have we. From then it could be organized though the wiki and this list.
What do you all think? How would curate? Can write access to a place like that be given?
I like this proposal a lot as it is now. I'd say it's a done deal in my book.
I'm very happy about that.
I would just take this email, maybe edit it a bit, and post it to this list as it's own distinct email with a header that highlights that it's a proposal to be accepted or rejected. Then we can wait several days, if there are no objections, do it.
Ok. I will do that. But first i think it would be good to line out and discuss the details. At first i was thinking that it could have been done in a wiki page, but we can do it here instead. I'll collect everything to be put in a final proposal for the exhibition part. Then the relevant wiki pages and folders could be made by someone with write privileges.
I do have some minor additions:
- curators cannot post their own work
- people add themselves to curator slots (wiki page or whatever)
- if curator slots are filled very far in advance, we change the
system then
Good points. The first is really about the form of each exhibition. I think the form should be as free as possible, such that curators can have there own still, even it can seam incoherent to some visitors. But still i think a minimum set of details should be in each exhibition. Here is a sketch:
- Some kind of header and footer. It could be very simple. The header could be just something like "Pd exhibition vol. <number>", and the footer could be simple information about the curator.
- Every thing in between is the exhibition.
- There should be no limit to the number of works in each exhibition. But my guess is that the range one to three would be fitting. Of cause less then one doesn't make sense. The reason i think more then three will be less fitting, is that i fear that the it will be less deep and less serious with too many pieces of work. Of cause, if it is a exhibition with a theme, like say samplers, it might make sense to the curator to give a serious and detailed presentation of the theme and then present quite a few works. This is just thoughts.
- For each piece the source should be available either at the exhibition site or liked to off site. I don't think it should be a must, but it definitely should be opted for!
- Also, proprietary media formats should not be used.
- formal Info on the artist should be supplied. At least a name and some sort of contact info or relation should be provided. The later could be a website url or organization name or band name or likewise.
- Description/presentation of the artist should be supplied. A roule of thump could be, that the less numbers of diffrent artist (per exhibition) the more detailed presentation of the artist(s) would be fitting.
A few other practical things that would be good to have sorted:
- Can we settle on simply calling it "exhibition" and placing the "public" part in ./exhibition/ ?
- Can we make certain wiki pages folders only readable for site users? I'm thinking that the organizing bit, the curator plan and the guideline for each exhibition, should not be directly public. I don't think we should do a lot to prevent people from seeing it, just not place it right next to the actual exhibition. So either make that bit only visible for site users, or just place it in ./community/projects/ exhibition/ instead of in ./exhibition/? The organizing bit need only two wiki pages, one for the info/planing stuff and one template wiki.
- To sum up; in the ./exhibition folder there will then be: An archive wiki with links to vol-<number> wiki's and an about wiki. The root of ./exhibition will still point to the current exhibition, ie. the newest.
- But, i'm not sure what to do with files like source- and media files. Should they reside just in the ./exhibition folder or in a dedicated files folder (./exhibition/files/) or should there be one files folder per exhibition? I think the later is too much trouble, and the fist might be a mess. So if a files folder can be made invisible in the menu, that would be best, i think.
And just to be clear, there should be one "official" overarching manager/moderator for the exhibition pages to set up the current pages, manage other questions, etc. I'll do this if no one else wants to, but it sounds like you are on it, Steffen.
Yup. I don't mind doing that. For a start anyways. Maybe in a years time or so, someone else wanna take over. We'll see how it goes.
This sounds very good, it's about time we did this!
Yeah.
Best, Steffen
On Mar 6, 2007, at 7:57 AM, Steffen wrote:
On 01/03/2007, at 3.48, Hans-Christoph Steiner wrote:
On Feb 28, 2007, at 5:55 PM, Steffen wrote:
On 28/02/2007, at 6.23, Hans-Christoph Steiner wrote:
and have a curated exhibition section.
If someone with sufficient privileges will set up a folder for it, where i/we can add wiki pages i'd give it a push. It could be /exhibition or /showroom or /gallery or slash-something-else. I'm not picky. It could also be in /community/projects, but i think thats hiding it away too much.
In that folder, i'd create
- a wiki page ./about with some general info about what the
exhibition/showroom/gallery is about.
- a wiki page ./organization or something like wise to use for
organizing it. Describing the procedure, what information and meta information there need be in each "issue"/"volume"/ exhibition and organizing who'll curate when.
- a wiki page ./archive with links to the past exhibitions.
Then all exhibitions, if i can decide, will have a wiki page each, named ./vol<number> or ./issue<number>. I think doing it this way is better then being monthly or bi-monthly, since then it can be sometimes monthly and some times bi-monthly - or what ever - without looking silly.
Apropos duration. I don't think an exhibition should laster less then a month. It's not to make it dull, but to give time to something serious to emerge. Separating it from the casual blog- sphere. In other words to give the curators time to make something interesting out of it, to increase quality!
The, say, /exhibition will point to the latest exhibition.
It would be good if a coming curator could be able to plan ahead and start making the wiki page before it goes "on air", hence some management in that direction would be needed. I don't know if one can just manually set the ./exhibition thing to point to a given wiki page, that might be the easiest way to realize both the archive, the pointer to the current exhibition and give coming curators the possibility to plan ahead. This also mean that the dir-listing that happens in the menu should be turned off for this folder or at least that future/planed exhibitions should be invisible.
A curator-to-be could build the wiki pages in their home folder, then they would be moved into the exhibition when the time comes.
That could be a solution, if it's not hard to move stuff about.
Also, today i tried to make a wiki page in my home folder, but it did not work. Now it just sits there, and i can't even delete it. I tried to make a folder in my home folder, but got much like the same error as when one in general tries to make a new wiki page. Hence there are some problems as is.
Seems like the permissions for the site are a bit askew. It should be possible for people to create wiki pages.
When it's set up and ready for action i could send a few PR emails. For example to Create Digital Music, .microsound- announce, Pd-announce and what have we. From then it could be organized though the wiki and this list.
What do you all think? How would curate? Can write access to a place like that be given?
I like this proposal a lot as it is now. I'd say it's a done deal in my book.
I'm very happy about that.
I would just take this email, maybe edit it a bit, and post it to this list as it's own distinct email with a header that highlights that it's a proposal to be accepted or rejected. Then we can wait several days, if there are no objections, do it.
Ok. I will do that. But first i think it would be good to line out and discuss the details. At first i was thinking that it could have been done in a wiki page, but we can do it here instead. I'll collect everything to be put in a final proposal for the exhibition part. Then the relevant wiki pages and folders could be made by someone with write privileges.
I do have some minor additions:
- curators cannot post their own work
- people add themselves to curator slots (wiki page or whatever)
- if curator slots are filled very far in advance, we change the
system then
Good points. The first is really about the form of each exhibition. I think the form should be as free as possible, such that curators can have there own still, even it can seam incoherent to some visitors. But still i think a minimum set of details should be in each exhibition. Here is a sketch:
- Some kind of header and footer. It could be very simple. The
header could be just something like "Pd exhibition vol. <number>", and the footer could be simple information about the curator.
Every thing in between is the exhibition.
There should be no limit to the number of works in each
exhibition. But my guess is that the range one to three would be fitting. Of cause less then one doesn't make sense. The reason i think more then three will be less fitting, is that i fear that the it will be less deep and less serious with too many pieces of work. Of cause, if it is a exhibition with a theme, like say samplers, it might make sense to the curator to give a serious and detailed presentation of the theme and then present quite a few works. This is just thoughts.
- For each piece the source should be available either at the
exhibition site or liked to off site. I don't think it should be a must, but it definitely should be opted for!
Also, proprietary media formats should not be used.
formal Info on the artist should be supplied. At least a name and
some sort of contact info or relation should be provided. The later could be a website url or organization name or band name or likewise.
- Description/presentation of the artist should be supplied. A
roule of thump could be, that the less numbers of diffrent artist (per exhibition) the more detailed presentation of the artist(s) would be fitting.
All good points.
A few other practical things that would be good to have sorted:
- Can we settle on simply calling it "exhibition" and placing the
"public" part in ./exhibition/ ?
Works for me.
- Can we make certain wiki pages folders only readable for site
users? I'm thinking that the organizing bit, the curator plan and the guideline for each exhibition, should not be directly public. I don't think we should do a lot to prevent people from seeing it, just not place it right next to the actual exhibition. So either make that bit only visible for site users, or just place it in ./ community/projects/exhibition/ instead of in ./exhibition/? The organizing bit need only two wiki pages, one for the info/planing stuff and one template wiki.
Should be possible, but I don't see the reason to hide content at all. It does make sense to have things in different places tho.
- To sum up; in the ./exhibition folder there will then be: An
archive wiki with links to vol-<number> wiki's and an about wiki. The root of ./exhibition will still point to the current exhibition, ie. the newest.
Sounds good.
- But, i'm not sure what to do with files like source- and media
files. Should they reside just in the ./exhibition folder or in a dedicated files folder (./exhibition/files/) or should there be one files folder per exhibition? I think the later is too much trouble, and the fist might be a mess. So if a files folder can be made invisible in the menu, that would be best, i think.
Probably one folder per exhibit/curator would work best.
Woo hoo, sounds like a plan!
.hc
And just to be clear, there should be one "official" overarching manager/moderator for the exhibition pages to set up the current pages, manage other questions, etc. I'll do this if no one else wants to, but it sounds like you are on it, Steffen.
Yup. I don't mind doing that. For a start anyways. Maybe in a years time or so, someone else wanna take over. We'll see how it goes.
This sounds very good, it's about time we did this!
Yeah.
Best, Steffen
------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
-
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Kyle Klipowicz -
marius schebella -
Steffen