From: Dan F <dfr...@cs...> - 2004-04-07 17:50:42
|
When I go to http://phpwiki.sourceforge.net/phpwiki and look for documentation, there are pages that describe behaviors, but I'm never clear if they are for the future, from the past, or currently implemented. Thus, it seems important to me to have documentation that is *per-release*. I took a shot at starting this scheme, and I solicit comments. See http://phpwiki.sourceforge.net/phpwiki/PhpWiki/1.3.7. The idea is that all the subpages of PhpWiki would be release numbers, so for example all the subpages of PhpWiki/1.3.7 would be correct and accurate descriptions of how 1.3.7 works. Issues: 1. This requires copying a lot of pages for each release we wish to document. However, this is actually true-- if we wish to isolate pages from changes, they must be copied. Thus, this seems okay. 2. Within each documentation page, instead of using SimpleLinks, it must have [ComplicatedLinks | PhpWiki/1.3.7/ComplicatedLinks]. This is unfortunate. I welcome better suggestions. 3. As the old markup is deprecated and dropped, I can imagine old documentation breaking. This is unfortunate. Options: a) document old versions with new markup b) have different sites running different versions c) not document old versions I suggest that 3a) is misleading, 3b) is a pain. 3c) is probably the answer, and that's probably okay. 4. It would be nice to document 1.3.8, not 1.3.7. Well, but 1.3.8 is not yet released, so that's hard to document. If people like this scheme, could we get volunteers to transfer a page or two from the chaotic parts of Phpwiki to the stable 1.3.7 docs? Then could we get the site admin to lock the pages? Dan |
From: Jeroen C. <je...@li...> - 2004-04-07 22:14:46
|
Dan F said the following on 04/07/04 19:50: > > 2. Within each documentation page, instead of using SimpleLinks, it must > have [ComplicatedLinks | PhpWiki/1.3.7/ComplicatedLinks]. This is > unfortunate. I welcome better suggestions. In my experience you should prefer simple links instead of sublinks. While sublinks are more correct from an information architectural point of view, they are complicated, you won't remember them, and they will cause less use of interlinking. Instead, why not just <PhpWikiRelease1.3.7>, or even <PhpWiki1.3.7>? Much simpler, less fuss with links, more intuitive in use. -- Jeroen Coumans (je...@li...) FAQ and Website Maintainer {faq,website}@linuxfromscratch.org www.jeroencoumans.nl |
From: Dan F <dfr...@cs...> - 2004-04-08 12:43:50
|
Jeroen Coumans wrote: > Dan F said the following on 04/07/04 19:50: > >> >> 2. Within each documentation page, instead of using SimpleLinks, it >> must have [ComplicatedLinks | PhpWiki/1.3.7/ComplicatedLinks]. This >> is unfortunate. I welcome better suggestions. > > > In my experience you should prefer simple links instead of sublinks. > While sublinks are more correct from an information architectural > point of view, they are complicated, you won't remember them, and they > will cause less use of interlinking. Instead, why not just > <PhpWikiRelease1.3.7>, or even <PhpWiki1.3.7>? Much simpler, less fuss > with links, more intuitive in use. Of course simple links are better if they meet the need. However, I don't understand how your suggestion meets the need I was describing. I proposed a tree under PhpWiki/1.3.7. Okay, suppose it is PhpWiki1.3.7 instead. If I wish to have a link on AddingPages to ClickTheQuestionMark, but I want both those pages to be local to the PhpWiki1.3.7 tree somehow, then I need a link like [AddingPages | PhpWiki1.3.7/AddingPages]. If I just link to AddingPages, it will not be for any particular version. Dan |
From: Reini U. <ru...@x-...> - 2004-04-07 22:15:23
|
Dan F schrieb: > When I go to http://phpwiki.sourceforge.net/phpwiki and look for > documentation, there are pages that describe behaviors, but I'm never > clear if they are for the future, from the past, or currently > implemented. Thus, it seems important to me to have documentation that > is *per-release*. > > I took a shot at starting this scheme, and I solicit comments. See > http://phpwiki.sourceforge.net/phpwiki/PhpWiki/1.3.7. The idea is that > all the subpages of PhpWiki would be release numbers, so for example all > the subpages of PhpWiki/1.3.7 would be correct and accurate descriptions > of how 1.3.7 works. Please just fix the CategoryNextWiki... links! All these relate to the 1.3.x branch, so they are still valid. CategoryNextWikiResearchAndDevelopment => CategoryNextWikiDone I already fixed a lot of thoxe pages, but there are still some more to fix. e.g. from CategoryNextWikiResearchAndDevelopment already Done is: # AllUsers not # ButtonMaker # CreateHomepage # EmailVerification # ExternalAuthentication # FrameInclude not # IndexAsConfigProblem not # InstallScript # NewBlockMarkup # NewDatabaseApiAndSchema # NewInlineMarkup # NewLoadZipOrDir # NewUserPreferences # PageChangeNotification not # PagePermissions not # PagingSupport # RateItPlugin # RateThisPage # RedirectTo # RenamePage not # SqlResultPlugin not # SqlWikiDbHookPlugin # SystemInfo # UserAuthentication # UserGroups # Utf8Migration # WikiAdmin # WikiAdminRename # WikiFarm # WikiUser > Issues: > 1. This requires copying a lot of pages for each release we wish to > document. However, this is actually true-- if we wish to isolate pages > from changes, they must be copied. Thus, this seems okay. > > 2. Within each documentation page, instead of using SimpleLinks, it must > have [ComplicatedLinks | PhpWiki/1.3.7/ComplicatedLinks]. This is > unfortunate. I welcome better suggestions. > > 3. As the old markup is deprecated and dropped, I can imagine old > documentation breaking. This is unfortunate. Options: > a) document old versions with new markup > b) have different sites running different versions > c) not document old versions > > I suggest that 3a) is misleading, 3b) is a pain. 3c) is probably the > answer, and that's probably okay. > > 4. It would be nice to document 1.3.8, not 1.3.7. Well, but 1.3.8 is not > yet released, so that's hard to document. > > If people like this scheme, could we get volunteers to transfer a page > or two from the chaotic parts of Phpwiki to the stable 1.3.7 docs? Then > could we get the site admin to lock the pages? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F <dfr...@cs...> - 2004-04-08 12:54:02
|
Reini Urban wrote: > Dan F schrieb: > >> When I go to http://phpwiki.sourceforge.net/phpwiki and look for >> documentation, there are pages that describe behaviors, but I'm never >> clear if they are for the future, from the past, or currently >> implemented. Thus, it seems important to me to have documentation >> that is *per-release*. >> >> I took a shot at starting this scheme, and I solicit comments. See >> http://phpwiki.sourceforge.net/phpwiki/PhpWiki/1.3.7. The idea is >> that all the subpages of PhpWiki would be release numbers, so for >> example all the subpages of PhpWiki/1.3.7 would be correct and >> accurate descriptions of how 1.3.7 works. > > > Please just fix the CategoryNextWiki... links! > All these relate to the 1.3.x branch, so they are still valid. > CategoryNextWikiResearchAndDevelopment => CategoryNextWikiDone > I already fixed a lot of thoxe pages, but there are still some more to > fix. This seems to miss my point. Perhaps you disagree with my suggestion, but I'd like to know you understood it, and hear your thoughts on it. I will restate: it seems important to have documentation *per release*. That is, I can visit the site and know that this page refers to version 1.3.7, which is the one I have installed. Right now, there is no such scheme. "CategoryNextWiki" will be out of date as soon as you release 1.3.8. Right now, it's never obvious when it's up to date, and most of the time I get the feeling it's not. When I get a release of high-quality software, I expect documentation that is finished and accurate for that particular version. I am looking for a substitute in the Wiki world. Think of it as an editor going through the pages and stamping some of them as, "This page is now accurate for version 1.3.7." Another way to do this would be to allow a page to be tagged with a symbolic tag, and allow users to view the site through that tag, but that feature is not present in the Wiki. A third way to do it would be social convention-- put at the top of every page: "This page describes the behavior of release 1.3.7." That phrase doesn't go on a page until it actually is complete. This is perhaps the easiest way to do it. The need for something like this is obvious to me. It's obvious to you, too-- look at how you release the software. You don't just keep updating CVS forever. At some point, you say there is a "1.3.8 release", you tag the software, bundle it, and offer the bundle. Documentation needs to be the same way if it is to be usable, and for the same reason. You shouldn't have to email out a list of which pages are finished to phpwiki-talk. It should be clear from visiting the Wiki itself. Most of your readers aren't necessarily subscribed to phpwiki-talk, and even if they were, you don't want to have to email the list over and over. Another usability item for documentation: there should be a "<< Previous" and "Next >>" button in each page, in order to offer a naive user a linear trail. Dan |
From: Reini U. <ru...@x-...> - 2004-04-08 15:55:23
|
<list policy> Please don't reply to all. Unless someone explicitly asks to be replied in private, each reply should go to the list only. </list policy> Up to date documentation more or less plus very old cruft is at the PhpWiki: site. Either for the old stable 1.2.x branch or CategoryNextWiki. Which don't contradict in most cases. Only the OldTextFormattingRules / TextFormattingRules were updated. Just some very old entries and ideas have to be refactored: MagicPhpWikiURLs has to be deprecated. MagicPages and MagicPhpWikiURLsExtension should be deleted. ... Per release documentation is shipped in the tar.gz in the pgsrc directory. Dan F schrieb: > Reini Urban wrote: >> Dan F schrieb: >>> When I go to http://phpwiki.sourceforge.net/phpwiki and look for >>> documentation, there are pages that describe behaviors, but I'm never >>> clear if they are for the future, from the past, or currently >>> implemented. Thus, it seems important to me to have documentation >>> that is *per-release*. >>> >>> I took a shot at starting this scheme, and I solicit comments. See >>> http://phpwiki.sourceforge.net/phpwiki/PhpWiki/1.3.7. The idea is >>> that all the subpages of PhpWiki would be release numbers, so for >>> example all the subpages of PhpWiki/1.3.7 would be correct and >>> accurate descriptions of how 1.3.7 works. >> >> Please just fix the CategoryNextWiki... links! >> All these relate to the 1.3.x branch, so they are still valid. >> CategoryNextWikiResearchAndDevelopment => CategoryNextWikiDone >> I already fixed a lot of thoxe pages, but there are still some more to >> fix. > > This seems to miss my point. Perhaps you disagree with my suggestion, > but I'd like to know you understood it, and hear your thoughts on it. > > I will restate: it seems important to have documentation *per release*. > That is, I can visit the site and know that this page refers to version > 1.3.7, which is the one I have installed. Right now, there is no such > scheme. "CategoryNextWiki" will be out of date as soon as you release > 1.3.8. Right now, it's never obvious when it's up to date, and most of > the time I get the feeling it's not. > > When I get a release of high-quality software, I expect documentation > that is finished and accurate for that particular version. I am looking > for a substitute in the Wiki world. Think of it as an editor going > through the pages and stamping some of them as, "This page is now > accurate for version 1.3.7." Another way to do this would be to allow a > page to be tagged with a symbolic tag, and allow users to view the site > through that tag, but that feature is not present in the Wiki. wiki uses Category tags for that kind of symbolic tagging. The Category BackLink shows all pages to which this page belongs to. > A third way to do it would be social convention-- put at the top of > every page: "This page describes the behavior of release 1.3.7." That > phrase doesn't go on a page until it actually is complete. This is > perhaps the easiest way to do it. > > The need for something like this is obvious to me. It's obvious to you, > too-- look at how you release the software. You don't just keep updating > CVS forever. At some point, you say there is a "1.3.8 release", you tag > the software, bundle it, and offer the bundle. Documentation needs to be > the same way if it is to be usable, and for the same reason. > > You shouldn't have to email out a list of which pages are finished to > phpwiki-talk. It should be clear from visiting the Wiki itself. Most of > your readers aren't necessarily subscribed to phpwiki-talk, and even if > they were, you don't want to have to email the list over and over. This is not done. I only occasionally email important core CVS fixes. Just if someone doesn't watch the phpwiki_checkins list, but if I expect that someone might rely on that. PhpWiki: site discussion is not duplicated here. From time to time we switch from list discussion to PhpWiki: discussion. > Another usability item for documentation: there should be a "<< > Previous" and "Next >>" button in each page, in order to offer a naive > user a linear trail. <?plugin PrevNext ...?> Once PhpWiki: is running 1.3.8 we can easily fix the structure with the WikiAdminSearchReplace plugin. E.g. add this line to the top of each page. Or fix the ...Done/ResearchAndDevelopment categories. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Alec T. <li...@sw...> - 2004-04-09 02:45:08
|
Reini, I have to agree with Dan on this. It is not obvious at all to someone visiting the PhpWiki website what features are in what version. A friend of mine I recently convinced to give PhpWiki a try was totally confused about whether page permissions, a feature he desired, was actually in the current version. I was also checking out the Upload plugin and came across a page on the PhpWiki Wiki describing various different versions and at least two different explanations on how uploaded images can be inlined. If this were documented in a release history, I would be able to actually go to the history and find out which version finally made it into the code base. Please don't feel I'm hassling you, I just think that this easily added release history would make life a lot easier for new users. Regards, Alec On Thu, Apr 08, 2004 at 05:55:48PM +0200, Reini Urban wrote: > <list policy> > Please don't reply to all. Unless someone explicitly asks to be replied > in private, each reply should go to the list only. > </list policy> > > Up to date documentation more or less plus very old cruft is at the > PhpWiki: site. > Either for the old stable 1.2.x branch or CategoryNextWiki. > Which don't contradict in most cases. Only the OldTextFormattingRules / > TextFormattingRules were updated. > Just some very old entries and ideas have to be refactored: > MagicPhpWikiURLs has to be deprecated. MagicPages and > MagicPhpWikiURLsExtension should be deleted. ... > > Per release documentation is shipped in the tar.gz in the pgsrc directory. > > Dan F schrieb: > >Reini Urban wrote: > >>Dan F schrieb: > >>>When I go to http://phpwiki.sourceforge.net/phpwiki and look for > >>>documentation, there are pages that describe behaviors, but I'm never > >>>clear if they are for the future, from the past, or currently > >>>implemented. Thus, it seems important to me to have documentation > >>>that is *per-release*. > >>> > >>>I took a shot at starting this scheme, and I solicit comments. See > >>>http://phpwiki.sourceforge.net/phpwiki/PhpWiki/1.3.7. The idea is > >>>that all the subpages of PhpWiki would be release numbers, so for > >>>example all the subpages of PhpWiki/1.3.7 would be correct and > >>>accurate descriptions of how 1.3.7 works. > >> > >>Please just fix the CategoryNextWiki... links! > >>All these relate to the 1.3.x branch, so they are still valid. > >> CategoryNextWikiResearchAndDevelopment => CategoryNextWikiDone > >>I already fixed a lot of thoxe pages, but there are still some more to > >>fix. > > > >This seems to miss my point. Perhaps you disagree with my suggestion, > >but I'd like to know you understood it, and hear your thoughts on it. > > > >I will restate: it seems important to have documentation *per release*. > >That is, I can visit the site and know that this page refers to version > >1.3.7, which is the one I have installed. Right now, there is no such > >scheme. "CategoryNextWiki" will be out of date as soon as you release > >1.3.8. Right now, it's never obvious when it's up to date, and most of > >the time I get the feeling it's not. > > > >When I get a release of high-quality software, I expect documentation > >that is finished and accurate for that particular version. I am looking > >for a substitute in the Wiki world. Think of it as an editor going > >through the pages and stamping some of them as, "This page is now > >accurate for version 1.3.7." Another way to do this would be to allow a > >page to be tagged with a symbolic tag, and allow users to view the site > >through that tag, but that feature is not present in the Wiki. > > wiki uses Category tags for that kind of symbolic tagging. The Category > BackLink shows all pages to which this page belongs to. > > >A third way to do it would be social convention-- put at the top of > >every page: "This page describes the behavior of release 1.3.7." That > >phrase doesn't go on a page until it actually is complete. This is > >perhaps the easiest way to do it. > > > >The need for something like this is obvious to me. It's obvious to you, > >too-- look at how you release the software. You don't just keep updating > >CVS forever. At some point, you say there is a "1.3.8 release", you tag > >the software, bundle it, and offer the bundle. Documentation needs to be > >the same way if it is to be usable, and for the same reason. > > > >You shouldn't have to email out a list of which pages are finished to > >phpwiki-talk. It should be clear from visiting the Wiki itself. Most of > >your readers aren't necessarily subscribed to phpwiki-talk, and even if > >they were, you don't want to have to email the list over and over. > > This is not done. > I only occasionally email important core CVS fixes. Just if someone > doesn't watch the phpwiki_checkins list, but if I expect that someone > might rely on that. > PhpWiki: site discussion is not duplicated here. From time to time we > switch from list discussion to PhpWiki: discussion. > > >Another usability item for documentation: there should be a "<< > >Previous" and "Next >>" button in each page, in order to offer a naive > >user a linear trail. > > <?plugin PrevNext ...?> > > Once PhpWiki: is running 1.3.8 we can easily fix the structure with the > WikiAdminSearchReplace plugin. E.g. add this line to the top of each > page. Or fix the ...Done/ResearchAndDevelopment categories. > -- > Reini Urban > http://xarch.tu-graz.ac.at/home/rurban/ > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > -- Evolution: Taking care of those too stupid to take care of themselves. |
From: Reini U. <ru...@x-...> - 2004-04-09 15:10:36
|
Alec Thomas schrieb: > I have to agree with Dan on this. So just do it, if you feel it's too odd. I'm not the PhpWiki: moderator. It's a wiki anyway. > It is not obvious at all to someone visiting the PhpWiki website what > features are in what version. A friend of mine I recently convinced to > give PhpWiki a try was totally confused about whether page permissions, > a feature he desired, was actually in the current version. > > I was also checking out the Upload plugin and came across a page on the > PhpWiki Wiki describing various different versions and at least two > different explanations on how uploaded images can be inlined. If this > were documented in a release history, I would be able to actually go to > the history and find out which version finally made it into the code > base. > > Please don't feel I'm hassling you, I just think that this easily added > release history would make life a lot easier for new users. > > Regards, > Alec > > On Thu, Apr 08, 2004 at 05:55:48PM +0200, Reini Urban wrote: > >><list policy> >>Please don't reply to all. Unless someone explicitly asks to be replied >>in private, each reply should go to the list only. >></list policy> >> >>Up to date documentation more or less plus very old cruft is at the >>PhpWiki: site. >>Either for the old stable 1.2.x branch or CategoryNextWiki. >>Which don't contradict in most cases. Only the OldTextFormattingRules / >>TextFormattingRules were updated. >>Just some very old entries and ideas have to be refactored: >>MagicPhpWikiURLs has to be deprecated. MagicPages and >>MagicPhpWikiURLsExtension should be deleted. ... >> >>Per release documentation is shipped in the tar.gz in the pgsrc directory. >> >>Dan F schrieb: >> >>>Reini Urban wrote: >>> >>>>Dan F schrieb: >>>> >>>>>When I go to http://phpwiki.sourceforge.net/phpwiki and look for >>>>>documentation, there are pages that describe behaviors, but I'm never >>>>>clear if they are for the future, from the past, or currently >>>>>implemented. Thus, it seems important to me to have documentation >>>>>that is *per-release*. >>>>> >>>>>I took a shot at starting this scheme, and I solicit comments. See >>>>>http://phpwiki.sourceforge.net/phpwiki/PhpWiki/1.3.7. The idea is >>>>>that all the subpages of PhpWiki would be release numbers, so for >>>>>example all the subpages of PhpWiki/1.3.7 would be correct and >>>>>accurate descriptions of how 1.3.7 works. >>>> >>>>Please just fix the CategoryNextWiki... links! >>>>All these relate to the 1.3.x branch, so they are still valid. >>>> CategoryNextWikiResearchAndDevelopment => CategoryNextWikiDone >>>>I already fixed a lot of thoxe pages, but there are still some more to >>>>fix. >>> >>>This seems to miss my point. Perhaps you disagree with my suggestion, >>>but I'd like to know you understood it, and hear your thoughts on it. >>> >>>I will restate: it seems important to have documentation *per release*. >>>That is, I can visit the site and know that this page refers to version >>>1.3.7, which is the one I have installed. Right now, there is no such >>>scheme. "CategoryNextWiki" will be out of date as soon as you release >>>1.3.8. Right now, it's never obvious when it's up to date, and most of >>>the time I get the feeling it's not. >>> >>>When I get a release of high-quality software, I expect documentation >>>that is finished and accurate for that particular version. I am looking >>>for a substitute in the Wiki world. Think of it as an editor going >>>through the pages and stamping some of them as, "This page is now >>>accurate for version 1.3.7." Another way to do this would be to allow a >>>page to be tagged with a symbolic tag, and allow users to view the site >>>through that tag, but that feature is not present in the Wiki. >> >>wiki uses Category tags for that kind of symbolic tagging. The Category >>BackLink shows all pages to which this page belongs to. >> >> >>>A third way to do it would be social convention-- put at the top of >>>every page: "This page describes the behavior of release 1.3.7." That >>>phrase doesn't go on a page until it actually is complete. This is >>>perhaps the easiest way to do it. >>> >>>The need for something like this is obvious to me. It's obvious to you, >>>too-- look at how you release the software. You don't just keep updating >>>CVS forever. At some point, you say there is a "1.3.8 release", you tag >>>the software, bundle it, and offer the bundle. Documentation needs to be >>>the same way if it is to be usable, and for the same reason. >>> >>>You shouldn't have to email out a list of which pages are finished to >>>phpwiki-talk. It should be clear from visiting the Wiki itself. Most of >>>your readers aren't necessarily subscribed to phpwiki-talk, and even if >>>they were, you don't want to have to email the list over and over. >> >>This is not done. >>I only occasionally email important core CVS fixes. Just if someone >>doesn't watch the phpwiki_checkins list, but if I expect that someone >>might rely on that. >>PhpWiki: site discussion is not duplicated here. From time to time we >>switch from list discussion to PhpWiki: discussion. >> >> >>>Another usability item for documentation: there should be a "<< >>>Previous" and "Next >>" button in each page, in order to offer a naive >>>user a linear trail. >> >><?plugin PrevNext ...?> >> >>Once PhpWiki: is running 1.3.8 we can easily fix the structure with the >>WikiAdminSearchReplace plugin. E.g. add this line to the top of each >>page. Or fix the ...Done/ResearchAndDevelopment categories. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F. <dfr...@cs...> - 2004-04-09 15:49:30
|
Reini Urban wrote: > Alec Thomas schrieb: > >> I have to agree with Dan on this. > > > So just do it, if you feel it's too odd. I'm not the PhpWiki: moderator. > It's a wiki anyway. Well now, as the most visible face of Phpwiki, people would like your blessing before going down a certain path. If you don't think it's a good idea, maybe it really isn't. Thus, people try to convince you. If you are convinced, then maybe you have suggestions for the idea that will make it better. Finally, even if you don't wish to be involved, it seems sensible to try to decide in the community what the best way is so we all pull in the same direction. That community seems to be on phpwiki-talk if anywhere. Moreover, in this case my suggestion (PhpWiki/1.3.7) had one large downside: complicated links. The large upside is per-release docs. The advantage of this is that since a release is fixed, the docs for it are clearly labeled and can get better and better without acquiring cruft. One can imagine some sort of tool support for this kind of thing; I suppose like Twiki "webs", where each web has simple links within it (and its own look and feel), but is isolated from the others. Is this interesting? In the current tool, what do people think of instead of having per-release docs, at least modifying a page to say at the top, "This is current for 1.3.7" and moving all discussion to page/Talk? This would at least make it clear and clean what each page addressed. Other questions: - Who is the PhpWiki moderator? Anyone? - The front page is locked. It could stand some editing as well. Who has access to it? Dan |
From: Reini U. <ru...@x-...> - 2004-04-09 17:30:23
|
Dan Frankowski schrieb: > Other questions: > - Who is the PhpWiki moderator? Anyone? > - The front page is locked. It could stand some editing as well. Who has > access to it? The PhpWiki developers which are listed at the sf.net project page. Please bear with me that I cannot answer your other policy question right now, because my net is working again (router hardware problem fixed) and I want to bring the 1.3.8 release out this weekend. Best today. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F. <dfr...@cs...> - 2004-04-09 19:30:41
|
Reini Urban wrote: > Dan Frankowski schrieb: > >> Other questions: >> - Who is the PhpWiki moderator? Anyone? >> - The front page is locked. It could stand some editing as well. Who >> has access to it? > > > The PhpWiki developers which are listed at the sf.net project page. Okay. > Please bear with me that I cannot answer your other policy question > right now, because my net is working again (router hardware problem > fixed) and I want to bring the 1.3.8 release out this weekend. Best > today. I am happy to wait. I'd like 1.3.8 out as well, so I can start porting to it. In general, as long as I know you are willing in principle to talk about some particular issue or question, I am happy to wait. I understand that you have 20 people emailing you about phpwiki all the time, and I don't. :-) Dan |
From: Reini U. <ru...@x-...> - 2004-04-10 00:45:31
|
Dan Frankowski schrieb: > I am happy to wait. I'd like 1.3.8 out as well, so I can start porting > to it. > > In general, as long as I know you are willing in principle to talk about > some particular issue or question, I am happy to wait. I understand that > you have 20 people emailing you about phpwiki all the time, and I don't. > :-) The problem are not the phpwiki mails, the real problems are more real world specific. My unstable router, and the instability in my testing environment right now. I don't know if I can fix the reported LDAP bugs, which gives me some headache if there's some fundamentally wrong in WikiUserNew. For example: Right now netbios over tcp/ip (SMB continuation messages get none or a wrong numbered ACK) goes wild, while raw TCP without any windows protocol is quite fine. Also some missing ACK packets, but no dramatic drop. Netbios seems to a fundamentally wrong protocol over instable wires. ... But disabling Netbios over TCP/IP doesn't change a anything in Win2000. It still uses SMB packets and no raw TCP/IP. Which is problematic for the 80MB hourly archiving and 140MB hourly streaming of our radio shows, where I'm currently working. PS: I enabled Arnaud's RssFeed plugin, which is a nice and easy feature. Sidebar seems to get better and better. EmailNotification seems to work fine. Just the diff code seems to be break, maybe on crlf / lf / cr issues. Sometimes the UnifiedDiff is correctly context specific, sometimes it just returns the whole page, but with the right +/- lines. No showstopper, but annoying on long pages. WikiGroups have a fundamental design problem, which I'm not willing to change for 1.3.8. But 1.3.9 will need a rewrite to be current_user independent. The problems only show up on the exp. _AuthInfo plugin, the problems with EmailNotifications are fixed. The gettext extension seems to broken on the sf.net server, maybe we should provide a index.php config option to workaround that. Similar to COMPRESS_OUTPUT. Immediate userpref theme/language changes did work in 1.3.4, if I remember correctly, but now we lost that feature. Well, this is a bit annoying and will lead to a lot of support questions. In the meantime I was able to add PHP CHM IDE support to XEmacs for Windows, if someone is interested. Posted to the php-mode.sf.net patches site. http://sourceforge.net/tracker/index.php?aid=932346&group_id=18584&atid=318584 C-c C-f is faster with the CHM than the original browser_url method. -- Reini Urban http://helsinki.at |
From: Dan F. <dfr...@cs...> - 2004-04-22 21:20:36
|
Dan Frankowski wrote: > Reini Urban wrote: > >> Alec Thomas schrieb: >> >>> I have to agree with Dan on this. >> >> >> >> So just do it, if you feel it's too odd. I'm not the PhpWiki: moderator. >> It's a wiki anyway. > > > > Well now, as the most visible face of Phpwiki, people would like your > blessing before going down a certain path. If you don't think it's a > good idea, maybe it really isn't. Thus, people try to convince you. If > you are convinced, then maybe you have suggestions for the idea that > will make it better. Finally, even if you don't wish to be involved, > it seems sensible to try to decide in the community what the best way > is so we all pull in the same direction. That community seems to be on > phpwiki-talk if anywhere. > In the current tool, what do people think of instead of having > per-release docs, at least modifying a page to say at the top, "This > is current for 1.3.7" and moving all discussion to page/Talk? This > would at least make it clear and clean what each page addressed. Reini (or other Phpwiki SourceForge developers), Any further comments on this? I would really like some docs whose version I understand. Thus, I'd like to 1. label pages in SourceForge's wiki "Current for version X" 2. move discussion to PageName/Talk 3. Have these two proposals at least slightly 'blessed' by the Phpwiki developers and community I am motivated again because I'm trying out EmailNotification, it's not working for me, and I sure wish I understood how it worked! So I am walking through the source, and after I understand it I'd be willing to put it in the Wiki .. if I know it will be in a doc tree that is at least somewhat cared for. So do you agree that 1 and 2 sound reasonable and I should go try it a little? Thanks for your attention. Dan |
From: Reini U. <ru...@x-...> - 2004-04-23 16:25:03
|
Clean up up the existing Phpwiki: wiki. It's there exactly for that purpose. But please don't break existing links from other wiki's. Dan Frankowski schrieb: >> Well now, as the most visible face of Phpwiki, people would like your >> blessing before going down a certain path. If you don't think it's a >> good idea, maybe it really isn't. Thus, people try to convince you. If >> you are convinced, then maybe you have suggestions for the idea that >> will make it better. Finally, even if you don't wish to be involved, >> it seems sensible to try to decide in the community what the best way >> is so we all pull in the same direction. That community seems to be on >> phpwiki-talk if anywhere. > >> In the current tool, what do people think of instead of having >> per-release docs, at least modifying a page to say at the top, "This >> is current for 1.3.7" and moving all discussion to page/Talk? This >> would at least make it clear and clean what each page addressed. > > Reini (or other Phpwiki SourceForge developers), > Any further comments on this? > > I would really like some docs whose version I understand. Thus, I'd like to > 1. label pages in SourceForge's wiki "Current for version X" > 2. move discussion to PageName/Talk > 3. Have these two proposals at least slightly 'blessed' by the Phpwiki > developers and community why not? > I am motivated again because I'm trying out EmailNotification, it's not > working for me, and I sure wish I understood how it worked! So I am > walking through the source, and after I understand it I'd be willing to > put it in the Wiki .. if I know it will be in a doc tree that is at > least somewhat cared for. So please add your comments on PhpWiki:EmailNotification, which is the default page for the EmailNotification documentation. > So do you agree that 1 and 2 sound reasonable and I should go try it a > little? Sure. It's a wiki. If someone doesn't like he will edit it away. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: <mal...@cs...> - 2004-04-13 23:38:13
|
On Wed, Apr 07, 2004 at 12:50:29PM -0500, Dan F wrote: > When I go to http://phpwiki.sourceforge.net/phpwiki and look for > documentation, there are pages that describe behaviors, but I'm never > clear if they are for the future, from the past, or currently > implemented. Thus, it seems important to me to have documentation that > is *per-release*. Should we possibly start a _separate_ dcoumentation Wiki, independent of the development Wiki? Malcolm -- Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ "Blessed are the meek, for they will inherit the earth." -- Matt 5:5 |
From: Dan F. <dfr...@cs...> - 2004-04-22 21:16:18
|
Malcolm Ross Kinsella Ryan wrote: >On Wed, Apr 07, 2004 at 12:50:29PM -0500, Dan F wrote: > > >>When I go to http://phpwiki.sourceforge.net/phpwiki and look for >>documentation, there are pages that describe behaviors, but I'm never >>clear if they are for the future, from the past, or currently >>implemented. Thus, it seems important to me to have documentation that >>is *per-release*. >> >> > >Should we possibly start a _separate_ dcoumentation Wiki, independent >of the development Wiki? > > Where would it live? Who would maintain it? I am not a huge fan of splitting off from SourceForge's main Wiki unless there is a compelling reason. On the other hand, if someone were willing to lead the charge, I would help if I could. Dan |