On Mon, 8 Nov 2010 20:10:51 -0800 Ian Caldwell <inchost...@gmail.com> said:
create the site first... THEN we'll consider if it can be used or not. we are NOt tearing down e.org right when we are releasing EFL. hell no. not happening. it stays and gets content and reshuffling. if in parallel you want to create a next-gen site.. then do that - but its a parallel project. as such dresb did this for the current ste, and before that i did it, and before that someone else did it and before that.. and so on back in history. i'd be more than happy not to have to spend my time on the website. i have enough to do. don't get me wrong. but i want it to be quality. in design. in look. in feel as well as content and layout. frankly the "code" used to run the site - i couldn't care less (as long as if it needs to be changed, it can be, easily). every scms that has been tried always has gotchas - can't format pages in a certain way, can't do something else, is slow, creates lag for website update.. or something. that's why in the end i wrote the php setup we have. it's simple and works. it's really just helper funcs. no major infra. tried drupal. tried joomla. tried mambo. have trac (bugs with things and slow), tried others too. i am no fan of going into scms's again. nb - we have multi-lang support on e.org - i wrote that. thats why the pages are en-* (english) and u can add de-* zh-* ko-* etc. (1 per lang). but fact is.. you don't see that done. too much content to go translate and keep up to date. > here's what we in all honesty Have to do. We need to ignore all the current > date, better yet move to e.org/old and we need to recreate a completely > BRAND new website, don't use any existing contest, just adapt and design > with a whole new approach in mind. Also there needs to be a team of > approximately 5-7 people (max) involved. We also need to be the > understanding that NOT everyone is going to be happy with the end result. It > needs to be a modern design with modern technologies similar to how drupal > did their major redesign. Also all code needs to be recreated none of the > old stuff used, and the new code needs to well commented and easy for joe > blow two years down the line to understand it. I'm willing to head up the > project. I have an idea and with a few select members working on a better > end result it will be better in the end. If we have any major questions of > course it'll be put to the group... The first step is all of the web > designers interested in helping I think it would be extremely helpful if you > made mockups of what you'd like the home page of E to look like, from there > we can all take a vote and make modifications as need be... > If someone disagrees feel free to speak it, but this is the best plan of > action in my opinion. Also I know people dislike the idea of this, but for > the fact of extensibility, I think it would be best to use a framework such > as drupal for the fact that #1 it comes with multilanguage, support and > various other features that we really don't need to recreate if need be. > Also it comes with roles so we can have designated people to post news, > designated people to maintain the main site etc. Lets face it... Gone are > the days of updating news via SVN posts... that's a bit archaic. I'm sorry. > Feel free to flame me if ya like. > Ian "Inc" C > On Mon, Nov 8, 2010 at 6:36 PM, Jesse Charbneau <j...@thecharbneaus.com>wrote: > > > Hello, > > I spend most of my days in web land supporting/debugging java, php, perl, > > sh (mainly tomcat, apache, mysql, etc). I’m wrapping up a side project, and > > with the holiday season coming up I’m sure I could spend some cycles helping > > out (least I could do considering the kickin’ libs and support I’ve used up > > over the years - literally Ecore_Threads is saving my arse right now, that > > fork pipe thing I had rolled up blew) ;-). > > > > > > Email me directly once things have been settled regarding priorities, whats > > needs updating, etc and I can setup something on my server or work with > > whomever controls that to dummy up the pages somewhere. While I’m also not > > a professional writer/copy person, I can do a fair enough job, so if > > proofreading / layout work is needed, I could probably help with that as > > well. Should also mention that English is my primary language and I pretty > > much suck at all others (minus programming) :-P. > > > > > > Thanks, > > Jess > > > > On Nov 8, 2010, at 8:58 PM, Gustavo Sverzut Barbieri wrote: > > > > > Well, I'll reply this mail with quite a bit of sadness... likely we'll > > > go nowhere from what you wrote. Maybe others can also reply with their > > > feelings. > > > > > > > > > On Mon, Nov 8, 2010 at 10:32 PM, Carsten Haitzler <ras...@rasterman.com> > > wrote: > > >> On Mon, 8 Nov 2010 18:32:54 -0200 Gustavo Sverzut Barbieri > > >> <barbi...@profusion.mobi> said: > > >> > > >>> Hi all, > > >>> > > >>> Raster is trying to solve our website problems by doing some work, but > > >>> looking at it from an outsider point of view (I've asked some) we're > > >>> not getting much better. I'm not even referring to look and feel, > > >>> graphics or similar inconsistencies, but contents. I'd like to > > >>> highlight the problems and propose a solution, that I'd take care of > > >>> finding someone to implement soon on ProFUSION's expense. > > >>> > > >>> = MOTIVATION = > > >>> Raster correctly want to keep website as a brochure, with the > > >>> essential and move more detailed stuff to trac. This is wise, and is > > >>> important to outsiders when they want to know what is E, EFL and they > > >>> don't have much time or patient to figure out using deep nested page > > >>> structure. > > >>> > > >>> Trac's wiki, on the other hand, would serve as full fledge resource > > >>> information, with all details and moving informations that require > > >>> updates. > > >>> > > >>> > > >>> = PROBLEMS = > > >>> Summary: Due legacy, pride or other unsolved problems we've crufted it > > too > > >>> much. > > >>> > > >>> Each page problem is listed below in separate sections. > > >>> > > >>> == ABOUT == > > >>> Cruft came due it being the first of new page sets. It was the only > > >>> place to talk about and we did it all in once. Check how many > > >>> references to our libraries we have there, and the level of details. > > >>> That is too much for an "about" page. Much of the details should be > > >>> offloaded to a "TECHNOLOGIES" page (more about it later). > > >> > > >> well about is this technologies page... effectively. no need to shuffle > > here > > >> for the sake of shuffling. > > > > > > The problem is that we have too much technologies. There we list just > > > 2 graphics (evas/edje) and it's too much already. > > > > > > IMO about page should be simpler, to let users grok what's E/EFL and > > > then lead to more specific bits. The current content is terrifying, do > > > some experiment: ask some random USER (as it's not specifically a > > > developer page) to read it and look at their face while they do it. > > > > > > > > >>> == DOWNLOAD == > > >>> Ouch, we're trying to solve one problem (lack of packages) with a page > > >>> that is not that helpful at all. This page should go, completely, > > >>> being replaced with a "TECHNOLOGIES" page (more about it later). The > > >>> current contents, such as Debian dependencies, and build order should > > >>> go to Trac to help with future packagers (Arch? BSD?), but this is > > >>> really a moving target and not something we should have in a brochure. > > >>> > > >>> I know at least Raster will be against that. But please stop for a > > >>> while and think why we need that. We should fix that problem and try > > >>> to get packages on distros. The current documentation is really > > >>> complex, it's hard if not impossible to expect users will read that > > >>> and get it right. For instance I just followed that to get it on my > > >>> temporary Fedora box and it was a no go, I resorted to other means to > > >>> get it running as it was not helpful for Fedora, just for > > >>> Debian/Ubuntu and there we should have packages! > > >> > > >> this is where i totally disagree. someone heard of e and was told it was > > good - > > >> or efl etc. and the internet has an attention span of about 2 seconds... > > they > > >> want to find where to get it right away with minimum of fuss. fact is > > any NEW > > >> release we do will take days, weeks or months to make it into any > > distro. > > >> ubuntu has 6 months release cycles. debian takes years between releases > > so > > >> current stable debian wont get a new version, if that's what you are on. > > fedora > > >> - same. 6 months or so, etc. do we just point to "hey you need to wait 3 > > months > > >> to get packages". or we do the usual and make tarballs available. in > > fact > > >> making the tarballs available of our releases *IS OUR PRIMARY TASK* i'ts > > even > > >> MORE important than the rest of the website. it *IS* our whole store and > > its > > >> merchandise. the brochure is begin handed out to people on the street > > they > > >> need to come into thew store and instantly see what they can get and > > where. the > > >> only thing i'd agree with is download maybe moving to the main index > > page! they > > >> are the #1 priority. we provide tarballs. getting them into distros is > > another > > >> matter. once there listing how to get efl/e per distro is a good thing > > "apt-get > > >> install X, emerge Y, pacman Z, yum ZZ" etc. yes - it may be a bit of a > > moving > > >> target, but brochures do change and get updated ad products, > > availability and > > >> distributors do. > > > > > > I totally disagree with you here, and I do have how to prove you > > > wrong. :-) You just need to try to understand it in an unbiased form. > > > > > > First of all, the information is important. For PACKAGERS. We must > > > keep it, for them. > > > > > > Secondly. Are we being effective with such page? > > > > > > - Try to find a single user that ever managed to install E/EFL from > > > that page, or similar pages. I doubt you'll find many. People just > > > look at it, then immediately look for packages. Most even try the > > > packages to realize they are not up to date (even if realize = mail or > > > IRC and we tell them). As a last resource they try our easy_e17.sh > > > (more on it later). > > > - Get some regular Linux user, don't even need to be a total > > > newbie, and ask him to follow that. Watch him doing it. Disaster, > > > likely the user will try something else before actually trying to > > > figure out what is wrong, likely try easy_e17.sh. > > > > > > I know that data quite well, from local friends that try it, or from > > > new ProFUSION employees that come along without previous EFL > > > knowledge. Most, if not all of these, are very experienced developers, > > > some even developers at KDE and Gnome camp. Still they will suffer. > > > > > > It is easy to have you to understand how they feel. Remember when you > > > try python-bindings and they fail badly at you, without you ever > > > knowing the reason. And without you having patient to solve it. > > > EXACTLY LIKE THAT :-) When you're experienced with one thing and > > > doing it daily, even the most complex stuff (like autotooling efl from > > > svn) is simple. When you're not, it becomes complicated and get's you > > > out of it. > > > > > > Now, looking at that page again, and at the above mentioned cases. Why > > > do we need to document something like that? It could be scripted. > > > > > > easy_e17.sh is always considered a side project. But it does exactly > > > what you describe in your page, also trying to be helpful about > > > dependencies and so on. Why not make that script official, ask people > > > to make it more foo-proof? Check it on other platforms like Fedora? > > > Face it, people will likely try that script instead of reading our > > > download page. > > > > > > Last but definitely not least on this topic: we really need to ship > > > packages. We have people to do it, at least for Ubuntu/Debian, Lutin > > > was always helpful to provide them and did not take that much time to > > > provide them. If we can provide some estimates about when we'll freeze > > > he can even prepare the boring part before. > > > Again, we're fixing the problem at the wrong place with this > > > download page. See http://www.gtk.org/download.html > > > > > > > > > > > > > > >>> == SUPPORT == > > >>> all fine, I'm listing it here so people don't think I forgot about it. > > >>> > > >>> == CONTRIBUTE == > > >>> Could someone ever read it all? I tried hard, but it took me a couple > > >>> of attempts to really do it. Boring, too much, not objective at all, > > >>> full of distractions. > > >> > > >> every page inst meant to be read from beginning to end - it has sections > > to > > >> find what you are after. it indeed may be a bit full of content, but at > > least > > >> it's up to date and accurate. > > > > > > I'm not arguing about sections, I see they are there and clearly easy > > > to find. But inside of them you still can't find what you want easily. > > > Similar to you, I'm not a professional writer, but it is easy to spot > > > when the text is clearly written or not. With the current text, seems > > > you try to justify too much the options, stuff that people will never > > > ever argue and even if they do argue, that's not a place for > > > discussion about english or not, autotools or not, svn or not... We > > > just need to make clear what and how we use stuff to get contribution. > > > > > > > > >>> Source: not something for brochure as it is. Too much, it should be a > > >>> wiki, and maybe more than one page. It replicates some information > > >>> from DOWNLOAD. At most we can explain some umbrella folders like > > >>> THEMES, MISC... > > >> > > >> well put it there. > > >> > > >>> Building: not something for brochure. Replicates what's in DOWNLOAD > > >>> and svn.enlightenment.org. > > >> > > >> i'm going to kill svn.enlightenment.org content. thats why it moved > > there. and > > >> it only covers a bit of whats on download. > > >> > > >>> Conventions: need to be more objective, straight to the point. The > > >>> lead text should be one short paragraph. > > >>> - Languages: need to be more objective. No point in phrases like "For > > >>> better or worse it is the one language most of us know better than any > > >>> other" > > >> > > >> ok - fair enough. > > >> > > >>> - Coding Style: need to be objective. Just say one should respect > > >>> existing style in that file otherwise patches will be rejected. Link > > >> > > >> this has failed. it doesn't work. so i started being more explicit. > > example of > > >> a right coding style. > > > > > > Not there. And your example there is just not helpful. I've asked > > > around before saying this to check if it was just me. We do need > > > examples, but not there. Just because we need more details, more > > > examples and they'll not fit there. We need to document as in plain > > > text the coding style, with examples for each stuff. Vincent Torri > > > sent us a good example of cairo or related, wee need something like > > > that... in a wiki page. Stuff that goes like: > > > > > > We indent with spaces only, 2 spaces after "if, while, for, do", 3 > > > spaces after braces. Examples: > > > if (x) return; > > > if (x) y; > > > if (x) > > > some_long_code_here_that_goes_over_80_chars_easily(); > > > > > > if (x) > > > { > > > some_code(); > > > here(); > > > } > > > > > > You guess it can become quite long list. But we need it as our style > > > is everything but "expected". I took about months to get used to it > > > and know what to expect. > > > > > > > > > > > > > > >>> to trac with actual definition of coding style and examples, > > >>> explaining of uncrustify and configuration for various editors -- > > >>> again, in TRAC. > > >> > > >> then move it over. > > >> > > >>> - Source Trees: need to be more objective, with the non obvious > > >>> things. It's fine to briefly explain our usage of src/{lib,bin}, data > > >>> and such, but we need to be concise and right to the point. > > >>> - Licenses & Copyright: really need to be more objective. Say we have > > >>> code in BSD and LGPL and patches to each project should respect the > > >>> project license. These days worth noting that we require no copyright > > >>> assignment and copyright holders are stored in AUTHORS and not in each > > >>> file header. > > >> > > >> agreed. > > >> > > >>> Join Us: really need to keep it straight to the point. Things like > > >>> id_rsa and info.txt are stuff that should be documented elsewhere. I'd > > >> > > >> disagree - this is pretty much fixed and not going to change. > > > > > > but there? Why there other than cruft it? We can even stick such stuff > > > into devs/README.txt as mostly nobody will ever need to check it out. > > > It's not the place for such specific information. > > > > > > > > >>> say something longer than 3 paragraphs is no go, we need to keep it > > >>> short to be accessible. 1 paragraph would be amazing, but we can have > > >>> 2 extra with more details, like pointer to wiki pages describing "easy > > >>> hacks", "debugging techniques" and so on. Commit access is something > > >>> we'll evaluate and even propose given contributions, so nothing we > > >>> should put on our brochure. > > >> > > >> we need to have it documented as to how this works. having it on our > > main site > > >> makes us look organised. i do agree the contribute page is a bit long, > > but i'm > > >> trying to give a baseline of information there and i wasn't going off to > > write > > >> N wiki pages too. moving some over is a good idea. > > > > > > ok. Probably after returning from Korea I'll look forward moving these > > > pages. Another option is do a wiki-cleanup day and have more people to > > > help. > > > > > > > > >>> == CONTACT == > > >>> Pointless as is. Replicates most of SUPPORT in a worse shape (yeah, I > > >>> know it was there before). I know we all like the dev map and the > > >>> people list, but it should not be there. Let's instead add a box in > > >>> SUPPORT with a link, something like "We have contributors around the > > >>> world, you can check who are them and where they live going to > > >>> <a...>devmap</a>" and a link to a page with developers list and a > > >>> map, maybe in future we add an smart way to relate the list to map. > > >> > > >> the support page doesnt mention all the mailing lists, only the most > > commonly > > >> used. also doesn't link to the archives. i like the dev map and dev > > list. i see > > >> no problems with them being here - what we could do is move mail lists > > to a > > >> sub-page like dev map and make this page JUST the list of active > > developers. > > >> since it's generated from devs/ it should stay as it self-updates. get > > rid of > > >> the rest of the stuff. just dev list as page and mailing list as sub > > page > > >> alongside dev world map. > > > > > > Why is the list of developers so important? Just because it used to be > > > there? Pride? > > > > > > First that page is confusing. Hard to find stuff, and I don't think it > > > deserves such highlight as a top entry of our website. It could also > > > use a cleanup, as half (or more) of the developers listed as active > > > are actually gone. Anyway I don't think that page is such important to > > > be as first level entry of the website and could all be sub links of > > > Contribute (You're listing contributors from contribute, help people > > > match IRC names -- cited in contribute -- to real names/faces, etc) > > > > > > > > >>> == DOCS == > > >>> I really dislike the current organization. Also docs were all pointing > > >>> to old stuff and I requested glima to replace the links with his > > >>> document that should be modern and up to date. > > >>> > > >>> Although not useless, I guess they would be better linked from a > > >>> TECHNOLOGIES page. > > >> > > >> i like docs. you have efl - most of our docs at the top and our primary > > focus > > >> when it comes to documentation. liks to further docs on the wiki, DR16 > > still > > >> there as it's still maintained... yes there was old stuff. i moved it > > off to > > >> the bottom in an attempt to "decommission" them. > > > > > > I'm not about removing the docs, just pointing to them from a > > > different place. Again, you know from memory what all those E* are in > > > the page, but not everybody deals with all technologies and beginners > > > (that usually use the docs) tend to have no clue what those names > > > are... and need to try one by one to find the correct E. > > > > > > > > >>> = PROPOSED SOLUTION = > > >>> While some fixes are just make the text more objective such as in > > >>> CONTRIBUTE and ABOUT, I'd like to propose: > > >>> > > >>> == REMOVAL == > > >>> DOWNLOAD (can keep it under downloads.e.org), CONTACT, DOCS (can keep > > >>> it under docs.e.org) -- although special domains I'd keep a simple > > >>> description + apache generated listing, like done with packages.e.org > > >> > > >> ugh. no no. this means keeping style, look and feel becomes a pain. so > > ... no. > > >> while i'd like to improve out directly listing thing on > > >> download/.enlightenment.org to look nicer - the raw "just browse" is > > nice. the > > >> brochure points to what you should care about (and thats what most > > people will > > >> look at anyway). > > > > > > I'm fine with not having them, could be a solution if you were really > > > against removing them :-) > > > > > > > > >>> == ADD == > > >>> TECHNOLOGY: This page would be a different approach of DOWNLOADS + > > >>> DOCS, with bits of CONTRIBUTE. The idea is to have a page with our > > >>> recommended technology (it may even contain some PROTO, but let's try > > >>> to keep with stable stuff). Each technology would contain: > > >>> - Name (ie: Evas) > > >>> - Short description (ie: stateful, retained mode, canvas library ...) > > >>> -- I'm bad at short descs, sorry :-P, it's a middle ground between > > >>> Evas description in DOWNLOAD and ABOUT. > > >>> - Screenshot/Video (where appropriated, like Elementary, Enjoy, > > Ephoto, ...) > > >>> - Actions Line: various links, such as > > >>> * download (link to snaphot/release) > > >>> * docs (link to doxygen) > > >>> * report a bug (link to trac) > > >>> * more (link to wiki page, could/should have dependencies, build > > >>> instructions...) > > >> > > >> we have about for that already. if that doesn't answer the common > > questions, > > >> then about needs to have improved content. it should be there. this is > > the > > >> first place someone will go when they go "what is this enlightenment > > thing?" > > >> and that should explain it. the download page is the "ok i know i want > > it or at > > >> least want to try it.. where do i get it?" page. it should instantly > > solve the > > >> problem in a way that WE can manage. WE can't manage debian, fedora or > > ubuntu > > >> release cycles. we CAN manage to put up our tarballs. > > > > > > Read again what I proposed. It is about each technology, providing a > > > meaningful description (maybe even visual) with the links to download, > > > docs, trac and wiki. > > > > > > Like: > > > <div class="tech"> > > > <img class="tech-screenshot" src="/i/screenshots/elm.png" /> > > > <dl> > > > <dt>Name:</dt> > > > <dd>Elementary</dd> > > > <dt>Description:</dt> > > > <dd>Widget set on top of Evas, Edje and Ecore that provides > > > lots of ready to use objects such as entry, high performance listings, > > > as well as a default theme to achieve a consistent look and feel > > > across applications. It's fully themeable for those that want custom > > > user experience. > > > </dd> > > > </dl> > > > <ul class="actions"> > > > <li class="download"><a > > > href="http://.../elementary.tar.bz2";>download</a></li> > > > <li class="docs"><a href="http://.../elementary";>docs</a></li> > > > <li class="wiki"><a href="http://.../elementary";>wiki</a></li> > > > <li class="bug"><a > > > href="http://.../newticket?category=elementary";>fill a bug</a>, <a > > > href="http://.../report?category=elementary";>view bugs</a></li> > > > </ul> > > > </div> > > > > > > From it you 1) know what that E means (Elementary), 2) know how to get > > > it, 3) know how to read about it and 4) how to check/fill bugs related > > > to it. All in one place, with extremely simple and easy access. > > > > > > > > >>> To me it is clear that this would provide better experience. We'd have > > >>> more space to explain what that name is, what is fundamental to > > >>> newcomers.... for us, old developers, it is fairly obvious what is > > >>> evas, expedite and evil, but ask someone that just joined the project > > >>> what they are! They get confused, as expected due the large amount of > > >>> "e" in our stuff ;-) So having a short paragraph to explain and > > >>> remember users what are those names is good. > > >>> > > >>> We can also do segmentation there, like CORE LIBRARIES, EXTRA > > >>> LIBRARIES, APPLICATIONS. > > >> > > >> this is partly or mostly on the wiki already. > > >> http://trac.enlightenment.org/e/wiki/EFL > > >> > > >> for efl. > > >> > > >> http://trac.enlightenment.org/e/wiki/EFLOverview > > >> > > >> for just an overview of it and how it all fits together. > > >> > > >> yes - it can become much better than a bunch of tables and 1-liners on > > each > > >> lib. the wiki page per lib can become a lot better. why isn't anyone > > helping > > >> out with all of that? most of the above stuff (some of it is good and > > right, > > >> most i think isn't) should be converted into effort in filling in the > > wiki with > > >> more content. > > > > > > Yes, the TECHNOLOGY page could be done in wiki, with specific parts > > > for Libraries, Apps and extra libs. So one less main section, which is > > > good. But OTOH you'd loose all references to docs/downloads from the > > > main brochure site. > > > > > > -- > > > Gustavo Sverzut Barbieri > > > http://profusion.mobi embedded systems > > > -------------------------------------- > > > MSN: barbi...@gmail.com > > > Skype: gsbarbieri > > > Mobile: +55 (19) 9225-2202 > > > > > > > > ------------------------------------------------------------------------------ > > > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > > > David G. Thomson, author of the best-selling book "Blueprint to a > > > Billion" shares his insights and actions to help propel your > > > business during the next growth cycle. Listen Now! > > > http://p.sf.net/sfu/SAP-dev2dev > > > _______________________________________________ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > ------------------------------------------------------------------------------ > > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > > David G. Thomson, author of the best-selling book "Blueprint to a > > Billion" shares his insights and actions to help propel your > > business during the next growth cycle. Listen Now! > > http://p.sf.net/sfu/SAP-dev2dev > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
