Re: wgo revamp timeline (proposal)
Thanks Sigurd for catching up with the deadline and publish the http://live.gnome.org/GnomeWeb/WebPolicies draft. Anyone willing to concentrate in authoring and licensing? It's the last urgent task looking for at least one person in charge. We only need a first draft, surely further ideas and improvements will come afterward. On Mon, 2006-07-10 at 21:59 +0200, Gergely Nagy wrote: Let's clean up the GnomeWeb wiki page while we are at it. Started: http://live.gnome.org/GnomeWeb -- Quim Gil /// http://desdeamericaconamor.org | http://guadec.org signature.asc Description: This is a digitally signed message part -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
Hi, On Thu, 2006-07-06 at 13:47 +0200, Quim Gil wrote: After the wgo revamp BoF meeting at Vilanova I'm in charge of pushing a list of tasks we agree to do during 2006, and a timeline. Here is the draft: http://live.gnome.org/GnomeWeb/DevelopmentTimeline Constructive criticism of the timelime follows :) I think this timeline, and the discussion that followed on this list focuses way too much on the actual CMS system used. First and foremost, I miss a list of goals to be achieved within this timeframe. The GnomeWeb wiki page lists some goals, but they seem too vague or ambitious for now. There are a lot of implicit issues with this timeline that need to be made more explicit, like the scope of the revamp. (I guess our goals are implicit too, but it's hard to grok for a newcomer to the project). There are no dependencies defined on the development steps. Not all involved people are visible. Let's see what we can do about that. I guess our main goal and scope for this timeline is to revamp the main www.gnome.org website, while not touching others (e.g. developer.gnome.org). We have to state our goals, and non-goals, i.e. what we don't want to do, or what we want to do later. Let's clean up the GnomeWeb wiki page while we are at it. We have to define what's wrong with the current implementation and what we can do about it. Easier navigation, better content, nicer theme, easier editing of content, I18N, etc. We need a list like that. We also need to define what's gonna be on the main gnome web site, and what's not. That's the partitioning part of the timeline. A lot of things depend on this. We might have to kick some content off the WGO site, and include something not yet there. Once we know what content we will provide on the site, we can define the authoring policies. Responsibles, licensing, translation, URL scheme, etc. Only then can we look at what technical means are necessary to fulfill the above mentioned list of goals. This will give us the specific requirements for a CMS system. The design of the site can be investigated parallel to all this. Theme problems can be identified, mockups can be made. Theme implementation can start as soon as we decided on the CMS. Actually, it could even influence the selection of the CMS. Sandbox systems must be set up for each candidate CMS to test features. Then, at some point we'll have to decide if the whole endeavor makes sense at all. Whether the new site will be actually better than the old version, and whether we can finish within the timeframe. I would call this our first milestone. Then, we have to set up a staging server, where the CMS can be installed and transitioning can begin. Old, but still relevant content has to be imported, new content written. Theme must be finalized. A very thorough testing must be conducted before flipping the switch. Add as many milestones until final release as necessary. As the first steps, I suggest to clean up the current GnomeWeb page a bit. Let's include some pimping for out efforts: state what's going on, list our top level goals, and describe how people can get involved (lists, irc). As people take responsibilities, let's list it there as well. Let it be an entry point for the revamp. We should also assess the current wgo state ASAP. Map the current content. Who were writing it? Are they still interested? Describe current system. Who was running it? How does it work? We'll need this info to justify why a new system is better. I realize that this may all be common knowledge to the people already involved with the wgo efforts. I guess I'm the guinea pig to test new contributors :) cheers, Greg -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
Hi, On Thu, 2006-07-06 at 13:47 +0200, Quim Gil wrote: After the wgo revamp BoF meeting at Vilanova I'm in charge of pushing a list of tasks we agree to do during 2006, and a timeline. Here is the draft: http://live.gnome.org/GnomeWeb/DevelopmentTimeline Constructive criticism of the timelime follows :) I think this timeline, and the discussion that followed on this list focuses way too much on the actual CMS system used. First and foremost, I miss a list of goals to be achieved within this timeframe. The GnomeWeb wiki page lists some goals, but they seem too vague or ambitious for now. There are a lot of implicit issues with this timeline that need to be made more explicit, like the scope of the revamp. (I guess our goals are implicit too, but it's hard to grok for a newcomer to the project). There are no dependencies defined on the development steps. Not all involved people are visible. Let's see what we can do about that. I guess our main goal and scope for this timeline is to revamp the main www.gnome.org website, while not touching others (e.g. developer.gnome.org). We have to state our goals, and non-goals, i.e. what we don't want to do, or what we want to do later. Let's clean up the GnomeWeb wiki page while we are at it. We have to define what's wrong with the current implementation and what we can do about it. Easier navigation, better content, nicer theme, easier editing of content, I18N, etc. We need a list like that. We also need to define what's gonna be on the main gnome web site, and what's not. That's the partitioning part of the timeline. A lot of things depend on this. We might have to kick some content off the WGO site, and include something not yet there. Once we know what content we will provide on the site, we can define the authoring policies. Responsibles, licensing, translation, URL scheme, etc. Only then can we look at what technical means are necessary to fulfill the above mentioned list of goals. This will give us the specific requirements for a CMS system. The design of the site can be investigated parallel to all this. Theme problems can be identified, mockups can be made. Theme implementation can start as soon as we decided on the CMS. Actually, it could even influence the selection of the CMS. Sandbox systems must be set up for each candidate CMS to test features. Then, at some point we'll have to decide if the whole endeavor makes sense at all. Whether the new site will be actually better than the old version, and whether we can finish within the timeframe. I would call this our first milestone. Then, we have to set up a staging server, where the CMS can be installed and transitioning can begin. Old, but still relevant content has to be imported, new content written. Theme must be finalized. A very thorough testing must be conducted before flipping the switch. Add as many milestones until final release as necessary. As the first steps, I suggest to clean up the current GnomeWeb page a bit. Let's include some pimping for out efforts: state what's going on, list our top level goals, and describe how people can get involved (lists, irc). As people take responsibilities, let's list it there as well. Let it be an entry point for the revamp. We should also assess the current wgo state ASAP. Map the current content. Who were writing it? Are they still interested? Describe current system. Who was running it? How does it work? We'll need this info to justify why a new system is better. I realize that this may all be common knowledge to the people already involved with the wgo efforts. I guess I'm the guinea pig to test new contributors :) cheers, Greg -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
Hi, On Thu, 2006-07-06 at 13:47 +0200, Quim Gil wrote: After the wgo revamp BoF meeting at Vilanova I'm in charge of pushing a list of tasks we agree to do during 2006, and a timeline. Here is the draft: http://live.gnome.org/GnomeWeb/DevelopmentTimeline Constructive criticism of the timelime follows :) I think this timeline, and the discussion that followed on this list focuses way too much on the actual CMS system used. First and foremost, I miss a list of goals to be achieved within this timeframe. The GnomeWeb wiki page lists some goals, but they seem too vague or ambitious for now. There are a lot of implicit issues with this timeline that need to be made more explicit, like the scope of the revamp. (I guess our goals are implicit too, but it's hard to grok for a newcomer to the project). There are no dependencies defined on the development steps. Not all involved people are visible. Let's see what we can do about that. I guess our main goal and scope for this timeline is to revamp the main www.gnome.org website, while not touching others (e.g. developer.gnome.org). We have to state our goals, and non-goals, i.e. what we don't want to do, or what we want to do later. Let's clean up the GnomeWeb wiki page while we are at it. We have to define what's wrong with the current implementation and what we can do about it. Easier navigation, better content, nicer theme, easier editing of content, I18N, etc. We need a list like that. We also need to define what's gonna be on the main gnome web site, and what's not. That's the partitioning part of the timeline. A lot of things depend on this. We might have to kick some content off the WGO site, and include something not yet there. Once we know what content we will provide on the site, we can define the authoring policies. Responsibles, licensing, translation, URL scheme, etc. Only then can we look at what technical means are necessary to fulfill the above mentioned list of goals. This will give us the specific requirements for a CMS system. The design of the site can be investigated parallel to all this. Theme problems can be identified, mockups can be made. Theme implementation can start as soon as we decided on the CMS. Actually, it could even influence the selection of the CMS. Sandbox systems must be set up for each candidate CMS to test features. Then, at some point we'll have to decide if the whole endeavor makes sense at all. Whether the new site will be actually better than the old version, and whether we can finish within the timeframe. I would call this our first milestone. Then, we have to set up a staging server, where the CMS can be installed and transitioning can begin. Old, but still relevant content has to be imported, new content written. Theme must be finalized. A very thorough testing must be conducted before flipping the switch. Add as many milestones until final release as necessary. As the first steps, I suggest to clean up the current GnomeWeb page a bit. Let's include some pimping for out efforts: state what's going on, list our top level goals, and describe how people can get involved (lists, irc). As people take responsibilities, let's list it there as well. Let it be an entry point for the revamp. We should also assess the current wgo state ASAP. Map the current content. Who were writing it? Are they still interested? Describe current system. Who was running it? How does it work? We'll need this info to justify why a new system is better. I realize that this may all be common knowledge to the people already involved with the wgo efforts. I guess I'm the guinea pig to test new contributors :) cheers, Greg -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
wgo i18n (was Re: wgo revamp timeline (proposal))
On Mon, 2006-07-10 at 10:08 +1000, Jeff Waugh wrote: ... and the i18n module still appears to be a patch, as well as terribly inefficient in terms of database access and design. As much as I enjoy Drupal, I really don't think it has a good answer to content translation at this point. All of us agree that Drupal i18n capabilities are not as good as our i18n requirements need. Although probably all we reckon as well that these requirements are not easy to fulfill by any CMS anyway, specially in the short term. However, we are approaching to a point of negotiation. Christian Rose has made some good observations at http://live.gnome.org/GnomeWeb/Localization and John Hwang seems to have an interesting proposal for a decent solution for now (I hope tavon and Greg Nagy come back from holidays so they can report by themselves). In the case we end up choosing Drupal, the i18n module has done some improvements. In v4.7 it doesn't require more patches to the core, it is a module that can be installed and upgraded cleanly. There is also a group of developers improving the Drupal support of XML and DocBook import/export. Surely all this is not enough to fulfill the requirements today but, well, is a promising path. Other paths are also feasible. We can consider them better once the requirements are agreed. At the very end it is all about free software programming and implementation: a sustainable negotiation between requirements, resources and deadlines. -- Quim Gil /// http://desdeamericaconamor.org | http://guadec.org signature.asc Description: This is a digitally signed message part -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo i18n (was Re: wgo revamp timeline (proposal))
On 7/11/06, Quim Gil [EMAIL PROTECTED] wrote: However, we are approaching to a point of negotiation. Christian Rose has made some good observations at http://live.gnome.org/GnomeWeb/Localization and John Hwang seems to have an interesting proposal for a decent solution for now (I hope tavon and Greg Nagy come back from holidays so they can report by themselves). Great, I'm looking forward to that. [...] Other paths are also feasible. We can consider them better once the requirements are agreed. At the very end it is all about free software programming and implementation: a sustainable negotiation between requirements, resources and deadlines. Certainly. I think your time-based approach of wgo development is the greatest thing like, ehm, the invention of sandals, as it allows things to actually happen instead of rotting away in endless discussion. Thanks! And I know that given a time based schedule, some things like even the full-scale i18n might end up being punted if we cannot get it to work in time. It's not like not having a localized revamped wgo would be a regression, compared to what we have now. So my main concern is to get the requirements right, so that we do not end up chosing a path that will make integration with our other localization effort (The GNOME Translation Project) more difficult than needs to be, even if we might not have that functionality from day 1 (due to the time constraints or lack of human resources). I still hope that we do, but then again, the schedule is aggressive. The goals are set high (at least the i18n requirements so far are), and no CMS that I know supports it out of the box, but the goals are set high for a reason: We want our web site localization to be at least as good as our software. If we can get this to work, then not only will it promote GNOME and the localization of GNOME in a terrific way, but I bet other projects that are looking for web site localization in a larger scale might be interested. Christian -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On Mon, 2006-07-10 at 21:59 +0200, Gergely Nagy wrote: First and foremost, I miss a list of goals to be achieved within this timeframe. True. New proposal: http://live.gnome.org/GnomeWeb/Goals There are no dependencies defined on the development steps. Dependencies are not shown, but they can be deduced from the deadlines. It needs improvement, sure. Tell what is unclear and I'll suggest clarifications. Not all involved people are visible. All people explicitly involved with responsibilities in the current release cycle are visible. If there are few names and many tasks unnamed is because we need more people to join, or the few of us will end up doing what we can (less, and probably worse). This is a reason that makes me feel *very* conservative planning changes for the current release. Let's clean up the GnomeWeb wiki page while we are at it. Yes. We only need to be careful not deleting and forgetting what was the result of long discussions and hours of work of previous and current contributors. We have to define what's wrong with the current implementation and what we can do about it. Easier navigation, better content, nicer theme, easier editing of content, I18N, etc. We need a list like that. I started the list of goals. Who wants to start this one? We also need to define what's gonna be on the main gnome web site, and what's not. What about starting really small, with few pages but really useful and exciting. Interesting texts with illustrative graphics, some screencasts, cool downloads and clear links to all the subsites. Translated to very few supported languages with strong translation teams willing to betatest. All wrapped with contemporary layouts with a GNOME desktop / Clearlooks identity and style. Once we know what content we will provide on the site, we can define the authoring policies. Responsibles, licensing, translation, URL scheme, etc. I disagree here, the policies can be defined without knowing the specific content of the current release. They need to be valid for more releases, and more subsites. Then, we have to set up a staging server, where the CMS can be installed and transitioning can begin. We need to negotiate the requirements of this server with the sysadmins. Some planned features and some elected software might not run properly on a server like i.e. the current Window with RHEL3. We should also assess the current wgo state ASAP. Map the current content. Who were writing it? Are they still interested? Describe current system. Who was running it? How does it work? We'll need this info to justify why a new system is better. Apparently Thomas Wood took the responsibility. Claus Schwarm is a needed counterpart. Both know a lot of the past and current state of gnome.org I guess I'm the guinea pig to test new contributors :) And you are doing very well. Myself am relatively new to this topic, as seemed to be many of the very active contributors at the GUADEC BoF. Hopefully we will be able to combine this fresh blood with the expertise of the ol'timers (most of them subscribed to this list and taking part in the revamp discussion). -- Quim Gil /// http://desdeamericaconamor.org | http://guadec.org signature.asc Description: This is a digitally signed message part -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
... and the i18n module still appears to be a patch, Are you talking about this http://drupal.org/project/i18n ?! as well as terribly inefficient in terms of database access and design. Don't know about this I really don't think it has a good answer to content translation at this point. The question is who has the best answer -- now -- not what is the best answer to our problems. Because the best answer to our problems would be (almost every time) to build our own framework but I don't think that there is enough hands but why not, if we target to build the next-gen desktop we could start with a new project which will take into account this new ideas and write from scratch. - Jeff We can't avoid Drupal because the i18n isn't completely mature. If the counter proposition is a wiki, it can be done with drupal. I guess that Mozilla.org use drupal with the mediawiki module. A.Amazigh -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On Sat, 2006-07-08 at 15:46 +0200, Murray Cumming wrote: I think this is very debatable. For instance, guadec.org was (is) far from perfect and, in fact, it lacks many points any decent website should have. None of the points you make have direct relation with the CMS, but to our lack of planning and resources. guadec.org never had an editors team as such. tavon planned a structure, applied and it was almost never touched. Myself I wrote most of the texts and at some point I didn't have time to write more. Other people contributed in the easiest way: posting a message in the forums. We didn't have time/resources to do it better. 1. Many people had difficulty finding information on the website due to: 1.1 the difficult-to-use structure. Our fault. 1.2 the lack of structure. For instance, information was often simply posted to the forums instead of being added to the main pages. These forum posts were almost impossible to find as soon as they had left the front page. Our fault. Also, we had to unable the search engine due to outdated packages in the server. 2. Almost nobody edited the pages, suggesting that they had some difficult in doing this compared to a wiki. This is probably why they (even you) used the forums. Even if you had changed the main pages, it would not have been easy to see what had changed recently, and it's currently impossible to view changes for a single page. This is doable with Drupal and many non-wiki-alike CMSs. I don't know whether these problems are due to the use of Drupal itself, but it did confirm my fears that Drupal might force us to create a web site that consists of news items. Not at all. You can build Drupal sites with the news and forum modules deactivated (to put an extreme example). The solution is to plan a good structure and get a team of regular editors working following the plan, not simply posting news on the fly. I have filed bugs for some of the things that make use of Drupal difficult compared to a wiki, and which make it like a news site, but I doubt that this is the full list: http://bugzilla.gnome.org/show_bug.cgi?id=341885 Probably 30' of a Drupal sysadmin. http://bugzilla.gnome.org/show_bug.cgi?id=341225 Probably 30' of a Drupal sysadmin. http://bugzilla.gnome.org/show_bug.cgi?id=334750 This might take longer, but it's doable. It has a component of personal taste (seems not to bother to many Drupal admins) but I guess it's about tweaking a bit of CSS and perhaps Drupal code. http://bugzilla.gnome.org/show_bug.cgi?id=334747 Probably 30' of a Drupal sysadmin. I mean, we can't expect a CMS to fit all our needs when installed out of the box. We need to care that the CMS chosen is able to integrate all the changes we need, and the default candidate keeps being able to integrate them. Sometimes is about configuring and installing additional modules. Sometimes will be about hacking and producing our own modules. The API and the module development are fully documented, so it is about our owj resources, basically. I did want us to have time to review guadec.org as the drupal test site before committing to drupal for gnome.org. I don't believe that guadec.org has proved that drupal is good enough for gnome.org, and I'm not confident that we would fix drupal problems easily for gnome.org if we couldn't fix them for guadec.org. Replicating the current wgo on a Drupal CMS can be done fairly easily. Many GNOMErs wouldn't probably notice it. From that point integrate improvements is just a matter of planning and execution. In particular, guadec.org completely failed to demonstrate that drupal is capable of supporting translated sites. Well, nobody offered to translate any content. At some point I stopped chasing Spanish and Catalan speakers because nobody seemed interested enough. Drupal i18n module was not even activated. In December 05 we started a discussion about Drupal capabilities for translated websites - http://mail.gnome.org/archives/gnome-web-list/2005-December/msg00120.html . Now it's time to fix the requirements and find if Drupal or the alternative CMS candidates can accomplish them. About Baris concerns about security. Drupal is a widely used platform. This makes it interesting for hackers finding holes, and they eventually find them. Security announcements are published at http://drupal.org/security (you can subscribe to reveive updated by email) and patches follow the announcements instantly or in few hours/days. Said that, we need to know for sure that the tools we are using are secure. Therefore I will be more than happy if you try to beat the CMS(s) we choose. -- Quim Gil /// http://desdeamericaconamor.org | http://guadec.org signature.asc Description: This is a digitally signed message part -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
Hi :o) About Drupal vs MediaWiki vs etc, there is not much point discussing tools before agreeing requirements. By July 17th Greg Nagy needs to come up with a list of requirements for the wgo platform (CMS). Help him with the requirements if you want to help selecting the most appropriate tool(s). That seems to make sense. Anyone know if there is there a place to discuss this, such as a wiki page, or should we contact mister Nagy by mail ? If you can't stop discussing the CMS to be chosen anyways, don't forget that after long debates Drupal is still the fittest candidate. If you think Tool X is better please explain why, the more detailed your comments are the most useful they will be. Sorry, but I just can't help myself :) I'd just like to mention Django [1], it seems a rather elegant solution. I'll post an argumentation as to it's advantages as soon as I get time, but while waiting I just wanted people to know it existed. That said, I cannot know yet if Django would meet the requirements. Love, Karderio [1] www.djangoproject.com/ -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On Sat, 2006-07-08 at 00:58 +0200, Quim Gil wrote: On Fri, 2006-07-07 at 12:25 -0300, Guilherme de S. Pastore wrote: [snip] And I did not make it clearer because I've already exposed this concern to qgil in the process of setting up drupal for guadec.org. As said, I don't think the problems were caused by Drupal but about the GNOME/GUADEC human context and the server infrastructure. However, many have pointed that one of the keys of the GUADEC 2006 success was the website. With all the problems we have got, the result seems to be much more satisfactory than the results obtained with the current wgo platform. I think this is very debatable. For instance, 1. Many people had difficulty finding information on the website due to: 1.1 the difficult-to-use structure. 1.2 the lack of structure. For instance, information was often simply posted to the forums instead of being added to the main pages. These forum posts were almost impossible to find as soon as they had left the front page. 2. Almost nobody edited the pages, suggesting that they had some difficult in doing this compared to a wiki. This is probably why they (even you) used the forums. Even if you had changed the main pages, it would not have been easy to see what had changed recently, and it's currently impossible to view changes for a single page. I don't know whether these problems are due to the use of Drupal itself, but it did confirm my fears that Drupal might force us to create a web site that consists of news items. I have filed bugs for some of the things that make use of Drupal difficult compared to a wiki, and which make it like a news site, but I doubt that this is the full list: http://bugzilla.gnome.org/show_bug.cgi?id=341885 http://bugzilla.gnome.org/show_bug.cgi?id=341225 http://bugzilla.gnome.org/show_bug.cgi?id=334750 http://bugzilla.gnome.org/show_bug.cgi?id=334747 I did want us to have time to review guadec.org as the drupal test site before committing to drupal for gnome.org. I don't believe that guadec.org has proved that drupal is good enough for gnome.org, and I'm not confident that we would fix drupal problems easily for gnome.org if we couldn't fix them for guadec.org. In particular, guadec.org completely failed to demonstrate that drupal is capable of supporting translated sites. But even if we don't have that review, or if don't use a new CMS, your revamp plan leaves lots of room for other improvements, and I like the idea of decisions being made at a certain point instead of waiting indefinitely. About Drupal vs MediaWiki vs etc, there is not much point discussing tools before agreeing requirements. By July 17th Greg Nagy needs to come up with a list of requirements for the wgo platform (CMS). Help him with the requirements if you want to help selecting the most appropriate tool(s). Yes. Sorry for braindumping too early. Feel free to simply refer back to this email at the appropriate time. [snip] -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
Another issue that we have to double check for any ready CMS system is the security. I'm not stating that Drupal is insecure or have such a bad history. But we have to bear in mind that any common CMS or Wiki application might have some security problems in future which might be problem for us as script kiddies would easily exploit the system. For that reason, we have to check the sources, and if necessary make some GNOME specific changes in all input/login processes. This way we might prevent some security problems to affect wgo/go before Drupal (or any CMS application chosen) team releases patch for them. I can put my work force after choosing CMS system to see if it's secure enough, and will try to make necessary fixes as much as my skills allow. On Sat, 2006-07-08 at 00:58 +0200, Quim Gil wrote: On Fri, 2006-07-07 at 12:25 -0300, Guilherme de S. Pastore wrote: However, I've already seen and faced all kinds of problems with drupal, from security to upgradability issues Could you be more specific about these problems? The ones I remember were not caused directly by Drupal but by a) lack of sysadmin resources or skills within the members of the GUADEC team with the permissions needed. b) GNOME permission policies having to satisfy the security of several tools, services, priorities and servers. c) outdated versions of several packages affecting the functioning of Drupal. d) lack of coordination between the GUADEC team and the Sysadmin team. We also tried an upgrade of a production site when Drupal 4.7 was still beta and without testing first on a development server. It didn't work: our fault. I bet now that 4.7 is more than stable the upgrade would be a child's game. I might be missing problems, please detail those that were caused by the Drupal code, not by we humans. , which IMHO do not make it the best option to set the infrastructure of a website we want to keep around for long on. Not having names for better alternatives doesn't help, as Jeff has pointed. :) You opinion as GNOME sysadmin is very important. Please make a list of requirements the tool(s) to be used should match and we will make sure the CMS(s) selected accomplish them. And I did not make it clearer because I've already exposed this concern to qgil in the process of setting up drupal for guadec.org. As said, I don't think the problems were caused by Drupal but about the GNOME/GUADEC human context and the server infrastructure. However, many have pointed that one of the keys of the GUADEC 2006 success was the website. With all the problems we have got, the result seems to be much more satisfactory than the results obtained with the current wgo platform. About Drupal vs MediaWiki vs etc, there is not much point discussing tools before agreeing requirements. By July 17th Greg Nagy needs to come up with a list of requirements for the wgo platform (CMS). Help him with the requirements if you want to help selecting the most appropriate tool(s). If you can't stop discussing the CMS to be chosen anyways, don't forget that after long debates Drupal is still the fittest candidate. If you think Tool X is better please explain why, the more detailed your comments are the most useful they will be. About i18n, there was a long discussion in gnome-web-list that got into quite detailed aspects back in December05-February06 (i.e. http://mail.gnome.org/archives/gnome-web-list/2006-January/msg00030.html ). John Hwang (aka tavon) is in charge of pushing the i18n policies draft by August 9th. If you want to get i18n right in wgo please help him summarizing what has been discussed and getting a good list of requirements. We don't have much time to discuss. If you want to help effectively it is recommended to a) concentrate your contributions in one topic until it is solved and b) try not to repeat discussions already held in the past if you don't bring new ingredients. signature.asc Description: This is a digitally signed message part -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
quote who=Guilherme de S. Pastore Il giorno gio, 06/07/2006 alle 14.02 +0200, Quim Gil ha scritto: July 26th: End of www.gnome.org revamp planning (aka feature freeze). Policies, licensing and wgo platform (CMS) agreed. *Please* not drupal. I think a worthwhile rule for this entire process should be: No criticism without solution. So please explain your point of view so it can be taken seriously, and offer a solution to go with it so you're also moving things forward. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ I think a lot of the basis of the open source movement comes from procrastinating students. - Andrew Tridgell -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On Fri, 2006-07-07 at 11:25 -0400, Guilherme de S. Pastore wrote: Il giorno sab, 08/07/2006 alle 00.06 +1000, Jeff Waugh ha scritto: I think a worthwhile rule for this entire process should be: No criticism without solution. So please explain your point of view so it can be taken seriously, and offer a solution to go with it so you're also moving things forward. Any strong reason that MediaWiki doesn't work? behdad I am not much into this CMS thing, so I regret not being able to suggest something absolutely certain of its capabilities and advantages. However, I've already seen and faced all kinds of problems with drupal, from security to upgradability issues, which IMHO do not make it the best option to set the infrastructure of a website we want to keep around for long on. And I did not make it clearer because I've already exposed this concern to qgil in the process of setting up drupal for guadec.org. Cheers, -- Guilherme de S. Pastore fatalerror -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On 7/7/06, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Fri, 2006-07-07 at 11:25 -0400, Guilherme de S. Pastore wrote: Il giorno sab, 08/07/2006 alle 00.06 +1000, Jeff Waugh ha scritto: I think a worthwhile rule for this entire process should be: No criticism without solution. So please explain your point of view so it can be taken seriously, and offer a solution to go with it so you're also moving things forward. Any strong reason that MediaWiki doesn't work? I only look at this from the i18n/l10n perspective, so please bear with me: From my understanding at looking at the MediaWiki source code, MediaWiki supports localization, but with the concept of one language per installation. I.e. if we want to have the web site translated into 42 languages, we need to maintain 42 separate MediaWiki installations and databases. This may be manageable for a site like wikipedia.org, but probably not for www.gnome.org. Ideally, there should be a minimum of efforts required to translate www.gnome.org -- if translating or enabling a particular translation requires sysadmin intervention, we simply won't have much (current) translated content at all. Christian -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
(Please keep marketing-list cc:ed) On 7/7/06, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Fri, 2006-07-07 at 19:26 +0200, Christian Rose wrote: On 7/7/06, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Fri, 2006-07-07 at 11:25 -0400, Guilherme de S. Pastore wrote: Il giorno sab, 08/07/2006 alle 00.06 +1000, Jeff Waugh ha scritto: I think a worthwhile rule for this entire process should be: No criticism without solution. So please explain your point of view so it can be taken seriously, and offer a solution to go with it so you're also moving things forward. Any strong reason that MediaWiki doesn't work? I only look at this from the i18n/l10n perspective, so please bear with me: From my understanding at looking at the MediaWiki source code, MediaWiki supports localization, but with the concept of one language per installation. I.e. if we want to have the web site translated into 42 languages, we need to maintain 42 separate MediaWiki installations and databases. This may be manageable for a site like wikipedia.org, but probably not for www.gnome.org. The one-per-installation locale is only relevant for the UI of the wiki, not the contents. So, while the Edit button will have the same English text in all pages, the content can be in almost any language without need for any further tweaks. There are certainly issues with dates, etc. But I'm not sure they obviously rule this greatly supported option out. Ok. I haven't looked too closely at the database scheme, so I didn't know this. Still, I think it may not be trivial to integrate our current localization efforts and localization process with a MediaWiki. Ideally, there should be a minimum of efforts required to translate www.gnome.org -- if translating or enabling a particular translation requires sysadmin intervention, we simply won't have much (current) translated content at all. Honestly I'm not really sure having translated website is such a good idea. What I think is good though is having per-language corners, better clearly separated through the URL (fa.gnome.org or gnome.org/fa for example. The latter is easier.) and let the language team publish their own content there, instead of trying to catch up translations of a moving target. Of course, things like press releases or announcements are and will be translated. We've reiterated this localized content discussion over and over for several years, and the consensus has always been that official content on www.gnome.org should have translations, while localized content provided by local communities belong on other local community sites. There are any number of reasons for this decision. The most recent time this was reiterated was on GUADEC. Is there something in particular about this decision that you dislike? Christian -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On Fri, 2006-07-07 at 21:28 +0200, Christian Rose wrote: (Please keep marketing-list cc:ed) /me blames evo Ideally, there should be a minimum of efforts required to translate www.gnome.org -- if translating or enabling a particular translation requires sysadmin intervention, we simply won't have much (current) translated content at all. Honestly I'm not really sure having translated website is such a good idea. What I think is good though is having per-language corners, better clearly separated through the URL (fa.gnome.org or gnome.org/fa for example. The latter is easier.) and let the language team publish their own content there, instead of trying to catch up translations of a moving target. Of course, things like press releases or announcements are and will be translated. We've reiterated this localized content discussion over and over for several years, and the consensus has always been that official content on www.gnome.org should have translations, while localized content provided by local communities belong on other local community sites. There are any number of reasons for this decision. The most recent time this was reiterated was on GUADEC. Understood. Is there something in particular about this decision that you dislike? My only problem is that a local community cannot easily register and host a domain name without a single point-of-failure/bottleneck, so, as long as we are offering communities some local space, I'm fine with that. Christian -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On 7/7/06, Behdad Esfahbod [EMAIL PROTECTED] wrote: We've reiterated this localized content discussion over and over for several years, and the consensus has always been that official content on www.gnome.org should have translations, while localized content provided by local communities belong on other local community sites. There are any number of reasons for this decision. The most recent time this was reiterated was on GUADEC. Understood. Is there something in particular about this decision that you dislike? My only problem is that a local community cannot easily register and host a domain name without a single point-of-failure/bottleneck, so, as long as we are offering communities some local space, I'm fine with that. Good point, but I really feel that is an orthogonal problem to the localization of the actual (and official) www.gnome.org content. Christian -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On Fri, 2006-07-07 at 12:25 -0300, Guilherme de S. Pastore wrote: However, I've already seen and faced all kinds of problems with drupal, from security to upgradability issues Could you be more specific about these problems? The ones I remember were not caused directly by Drupal but by a) lack of sysadmin resources or skills within the members of the GUADEC team with the permissions needed. b) GNOME permission policies having to satisfy the security of several tools, services, priorities and servers. c) outdated versions of several packages affecting the functioning of Drupal. d) lack of coordination between the GUADEC team and the Sysadmin team. We also tried an upgrade of a production site when Drupal 4.7 was still beta and without testing first on a development server. It didn't work: our fault. I bet now that 4.7 is more than stable the upgrade would be a child's game. I might be missing problems, please detail those that were caused by the Drupal code, not by we humans. , which IMHO do not make it the best option to set the infrastructure of a website we want to keep around for long on. Not having names for better alternatives doesn't help, as Jeff has pointed. :) You opinion as GNOME sysadmin is very important. Please make a list of requirements the tool(s) to be used should match and we will make sure the CMS(s) selected accomplish them. And I did not make it clearer because I've already exposed this concern to qgil in the process of setting up drupal for guadec.org. As said, I don't think the problems were caused by Drupal but about the GNOME/GUADEC human context and the server infrastructure. However, many have pointed that one of the keys of the GUADEC 2006 success was the website. With all the problems we have got, the result seems to be much more satisfactory than the results obtained with the current wgo platform. About Drupal vs MediaWiki vs etc, there is not much point discussing tools before agreeing requirements. By July 17th Greg Nagy needs to come up with a list of requirements for the wgo platform (CMS). Help him with the requirements if you want to help selecting the most appropriate tool(s). If you can't stop discussing the CMS to be chosen anyways, don't forget that after long debates Drupal is still the fittest candidate. If you think Tool X is better please explain why, the more detailed your comments are the most useful they will be. About i18n, there was a long discussion in gnome-web-list that got into quite detailed aspects back in December05-February06 (i.e. http://mail.gnome.org/archives/gnome-web-list/2006-January/msg00030.html ). John Hwang (aka tavon) is in charge of pushing the i18n policies draft by August 9th. If you want to get i18n right in wgo please help him summarizing what has been discussed and getting a good list of requirements. We don't have much time to discuss. If you want to help effectively it is recommended to a) concentrate your contributions in one topic until it is solved and b) try not to repeat discussions already held in the past if you don't bring new ingredients. -- Quim Gil /// http://desdeamericaconamor.org | http://guadec.org signature.asc Description: This is a digitally signed message part -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
After the wgo revamp BoF meeting at Vilanova I'm in charge of pushing a list of tasks we agree to do during 2006, and a timeline. Here is the draft: http://live.gnome.org/GnomeWeb/DevelopmentTimeline Highlights: we can follow the GNOME release cycle, unveil the wgo revamped on September 6th (English only) and release the official translations on October 4th. It's a tight agenda but doable, a lot of planning and discussion has been done and most of us seem to work better with some action, and pressure. It needs discussion but... it needs specially people assuming the responsibility of a task. Otherwise the planning is useless, pure utopia. If you wanted to rise your hand now it's the time. Old and new faces are welcomed. Hopefully, like the GNOME release schedule, if a feature is not sufficiently ready on time, it will be punted to the next release schedule. For instance, if a suitable CMS is not found, or the translation feature of a CMS is not ready, the other stuff will not wait for it. Otherwise, an item can delay the whole thing indefinitely. Of course, I trust you to decide if a feature is sufficiently ready. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
Re: wgo revamp timeline (proposal)
On Thu, 2006-07-06 at 13:53 +0200, Murray Cumming wrote: Hopefully, like the GNOME release schedule, if a feature is not sufficiently ready on time, it will be punted to the next release Definitely: July 26th: End of www.gnome.org revamp planning (aka feature freeze). Policies, licensing and wgo platform (CMS) agreed. Any core part not defined at this stage will wait to the next release cycle. Minor parts being planned/developed after that date might be added to the current release if we think they are useful and won't affect negatively the release process. For instance, someone coming up with something great s/he has done and can be integrated as plug and play. But we have no obligation to include anything coming after the feature freeze. This is a way to guarantee that we will have a new website when GNOME 2.16 is released. -- Quim Gil /// http://desdeamericaconamor.org | http://guadec.org signature.asc Description: This is a digitally signed message part -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list
