On Tue, Nov 9, 2010 at 1:59 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Mon, 8 Nov 2010 21:36:27 -0500 Jesse Charbneau <j...@thecharbneaus.com> > said: >> On Nov 8, 2010, at 8:58 PM, Gustavo Sverzut Barbieri wrote: > > for some reason your reply has been lost in my mailbox. damn! so i'll reply to > the reply... :) > [...] >> >>> == 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. > > we need it for much more than packagers. if i don't find a place i can > download > the software from in about 10 seconds. i give up. i don't bother. it's too > hard. this is normally after trying apt-get install <software name>. so > packaging info is already going to be tried. but the information is HELLISHLY > IMPORTANT for everyone. packagers will always be behind our releases. fact is > you have companies like samsung and others whose FIRST port of call isnt > looking for distro packages - it's looking for tarballs of source. once our > stuff is packaged - our download page is not even useful anymore as people > already get it direct from their distro, but until that point, it's the only > reliable place to get our releases. > > need i say more: http://www.kernel.org/ > > thats what people CARE ABOUT. do most users go to kernel.org to get their > linux > kernel? no - its packaged and build by a distro, but that is the primary > purpose of the kernel developer team - to produce the source tarballs. that is > our primary purpose as well. thus it is a major thing that has to be in big > bold links on our site and dead-easy to find/get to.
Well, you nailed it... but you consider it to the wrong point. We'll keep our tarballs, always. They will be in the downloads.enlightenment.org, that we can link from our site. But all you wrote there, as you wrote, is just useless and brings nothing good. All the information about Debian dependencies and instructions on how to build? Check the gtk or kernel pages, all they mention is stable/dev version and download link. That's it. I'm ALL FINE with it. If it is simple enough we can even have that link only from the start page. Like "Stable release" that links to http://downloads.enlightenment.org. If we keep a directory /releases/STABLE with links to the latest stable tarballs that becomes very simple for users and us (so they're not hammered with thousand packages). However I'm quite against one link per sub-module in the main page. Pointless, for the reasons mentioned everywhere in my text. Either get to the folder and download all, if you know it a bit, you download just a subset... or use the technologies page to understand what is that E* and download it from there. >> > 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). > > that's because of what i explained - distros are ALWAYS behind. or they just > don't package it. as such e hasnt been packaged with distros in the past, but > be that as it may, our primary reason in life is to deliver THOSE tarballs. I'm not against the tarballs. I'm against the way they are being presented. > there is NO WAY we can do anything else. how many distros are *WE* going ot > make packages for? we aren't. we are just going to have to wait for packagers > of distros to catch up and note it on that page when that is the case. if we do for 4 major we're covering the vast majority (Debian, Ubuntu, Suse and Fedora -- actually 2 sets should do). >> > - 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. > > because regular linux users have lost any ability to compile anything. they > are > bound to their distros packagers. and as i said - that is a SEPARATE matter. But one we must address. Actually this is the only point of it, have people to use our software. If they've lost ability to compile stuff, we must aid them. >> > 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. > > it should be packaged... but that DOESNT change the fact that our primary > purpose is to deliver the source tarballs. it is FROM those that everything > builds. building from svn scripts is simply a shortcut "for now" because we > havent released stable stuff. > >> > 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 > > dependencies? where? i see no apt-get in it... not a single dependency listed > and/or installed (from gcc through to libpng-dev etc. etc.) > >> > 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. > > easy-17 sucks in half of svn and then peolpe complain about things being buggy > and not working because a lot of what it builds and sucks in is unmaintained > or just unstable and not quality enough - e-modules-extra. need i say more. > > but again... that doesn't change the fact that our JOB is to deliver those > source tarballs. what happens after that is another stage - packaging for > distros, scripts that "build it for your distro" etc. etc. > > east-e17.sh doesnt fix up the problems of things like making sure your distro > has the right dependencies to build something at all or build something > usable. > frankly you either make easy-e17.sh handle all the most popular distros AND > install deps AND build, or you make N scripts, 1 per distro to do the same, > or.. u leave it to packagers. Okay. That IS addressable. And actually easy, even easier given that we're talking about the particular subset that we consider "releasable". We can improve that script, or write a simpler script that handles Ubuntu, Debian, Fedora and Suse, testing them in VM. >> > Last but definitely not least on this topic: we really need to ship > > WE can't ship them... distros dont let us ship THEIR packages. they want to > ship their own. we can't control that. just look at all the arguments you've > had with gentoo developers and users. debian have strict policies. if you are > not a debian developer you cant add packages to debian. only debian developers > can. i can go on. you did have a separate overlay for efl and that caused all > orts of unhappiness around gentoo land. we could have our own apt repository > for ubuntu/debian and build our own packages... but the people doing that now > do it outside of our development environment, so again - it's the next stage > in > a pipeline that is out of our control. These distros all use the concept of overlays or extra repositories to provide fresher or testing software. We'd be yet another one. They need it already, for instance if you want multimedia codecs, proprietary applications and so on. To support that, they even PROVIDE us with build machines and infrastructure. We can ship Ubuntu packages to PPA, Fedora and Suse can use OBS. Problem with that and the easy_e17.sh is they're not coupled with core project. On one hand, is their fault as they vanish (maybe due the task being boring, big and return not so valued). But on the other hand it is OUR (core developers) fault to not support and provide the required resources these folks. For couple of years we just ignored, pushed aside or even bashed the packagers. Or the package users. "Are you using packages? Booooo... go away, you're bad, use from svn or I'll not talk to you". Thus the dudes doing the huge amount of work to get packages are always marginals to our process. I've tried to do announcements of freezes and snapshots to solve that problem. They said to me it was helpful, but we did very very bad at meeting the deadlines, thus useless. But the idea of integrating the packagers in our life cycle is good so they can prepare... and not just wake up one day and check their mail that E did released a set of packages. >> > 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. > > as i said - he does it, but does it totally separately - the best we can do is > give information as to how to install those packages once they are available. > i > never have seen an announcement of them being made/updated after we have done > releases/snapshots, so i have no idea whats going on there. if lutin were to > send emails announcing such things then we'd know and be able to put up the > relevant information on the download page. > > your argument is that all the tarballls offered for download are confusing and > that we shouldnt have that, instead we should have packages or scripts. guess > what? the packages dont exist (ie we do a release.. and.. is there, that very > same day, packages for debian? no.). we release tarballs. then a next stage > produces packages. once they are poroduced i have no problem having > information > on their availability. in fact the download frames per lib should include the > relevant distro packages once they are updated and provided by the said > distros. (ie apt-get install x, y, z etc. etc.). As I said, it's separated and marginal since we pushed them all away. We need to fix that. We'll keep the tarballs, just not need to add a long table of boxes with buttons for each library to download the package. It is worth nothing. A simple directory with "wget -r" able will do, much better. Or expectable locations so scripts can ge them, even if script is a simple: for p in eina eet evas ecore edje...; do wget $URL_BASE/$p; done >> > Again, we're fixing the problem at the wrong place with this >> > download page. See http://www.gtk.org/download.html > > ooh look at that. "svn" info (git in theory case) and... directly link to a > page with the tarballs. nothing about packages. no build instructions, help or > order information until you click down lots of levels. instead of several > links > away its all on one page. it is in essence no different to the gtk thing, but > just a bit flatter. unlike gtk we have many more packages. That's how we expose it. Gtk also have lots of packages and depencies, maybe even more than we do to support it (glib, cairo, pango, atk, ...) >> >>> == 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. > > look. what is frustrating about your "well lets do this" mail is.. you know > what will happen? nothing. nada. no one will do anything. i've created > content. > i've created information that isn't documented anywhere. the page content has > improved radically from what it was before i just did an overhaul now. there > is > actual content with useful information now. there wasn't before. if you want > to > put it over in the wiki and make e.org pretty much empty... then i'll oppose > that. having pages that have nigh on no content because "its off in the wiki" > looks stupid. why bother having a page or a site at all then? we need to draw > a > line on what is "official" and what is "fluid". official stuff goes on e.org > main - fluid stuff goes in wiki. official stuff directly impacts our image to > the world and thus shouldnt just be a free-for-all to edit as they like. I just disagree with that, again. Things will happen, if we coordinate. We're bad at coordinating, and delegating. Particularly you need to fix that with your workflow. I know you're the one that is pushing the project forward for +12years. But if you don't change your work flow you'll remain like that forever. In 20 years you'll be the one doing the code, debug, packages, tarballs, website, bug triage and even re-answering already answered mails at e-users. Okay, not everybody is paid to work at E/EFL, but some of us would not matter committing to some tasks and being requested about their status. Maybe that would even help people to get motivated finishing their tasks, as sometimes it seems that nobody cares about what they are doing. So let's learn how to manage more, hack less? >> >>> 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. > > i started with a small snippet. please turn it into the page you describe. i > got off my arse and did things. the site has been stagnant for months and > months. i tried to get some momentum in fixing it up doing the about page a > while back. no one followed. i have precisely zero faith in anyone doing > anything other than me because history shows thats what happens. make the > "coding styles" wiki page WITH all the examples that you want to be there as > you describe.. then once you have that, remove most of that section and point > it to the wiki page. same with everything else. until then, it stays. if you > don't want to or can do it. if you don't have time - convince someone else to > do it. until it gets done though, it stays. fair enough. And that's what I'm trying to do. But instead of just simply going and changing everything you did, I'm trying to get some opinions to do it better once, than do it partially and require yet another one to jump in and rewrite what I did. >> >>> 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. > > it looks professional to document how you become a developer and shows that we > are not some mysterious group. like you say with "download". look at it from > the perspective of "i know nothing about open source and working with other > developers out there. it's a totally foreign model to me" point of view. you > need to show that there is a simple path to becoming a developer, and that the > information needed is easily produced. if i could make it a web form and a > bunch of automated php (ie i hate the time to do it and make it secure) i > would > - and i'd have it on the main site. Fair, but does not need to be there. People often have stuff to do, instead of roles to get. If we lack something in that contribute page to get people motivated is "how do I get started", probably a list of links to specific wiki pages: - foreigners: translations and localization. Learn more (links to our translation team, explain tools and all) - graphical design skills: create or improve themes, documentation or website. Learn more (links explaining where icon sources are stored, some guidelines, etc) - writing skills: write about our technologies, how tos and if you happen to know how to code, improve our documentation. Learn more (links to guidelines on how to get blog posts, how tos and gettext for api docs) - coding skills: C, C++, Python, JavaScript developers can help by fixing bugs or implementing missing features. Learn more (some trac wiki with easy hacks, or a bug report with filtering by "easy" status). In the current website we lack all but simple way for C hackers, ignoring everyone else. And we try to concentrate people at the core, what WE deal most, but scares most of the project new comers. >> >>> 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. > > good luck. history says this won't happen. let's see ;-) >> >>> == 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? > > i get asked too often "how many developers do you have?". a list of them > answers that. and yes - it's a matter of pride. that a developer can take > pride > in being part of a team and contributing to something. as such that list also > gives you the person to contact for a given thing - eg you want to hack on > evas > - you can find out who is in charge there. it puts a human face on our > development. it's important. If you want to make up numbers, that is fine. But they are inconsistent. We have couple of developers without dev/ dirs (they send random patches), OTOH a huge amount of the people listed there just left the project. I'd also link to developers of certain technology from its page, if you want that relationship you mentioned. Right now it's just hard to find people there. You must resort to browser "search" to get to it. >> > 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) > > well half of those developers still have svn access. i dont think its a > problem > of the page -but a problem that we don't actively remove developers from our > devs dir often enough. don't shoot the messenger. the page is just the > messenger. i also don't want to change the top bar/tab list of entries (news, > about, download, support, ...) because all our docs are generated with that > same template and that means we have to fix them all up. in addition trac is > set up with the same template. we have to go change them all. i do not want to > go change them now anymore. too close to release. > >> >>> == 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. > > the docs are api docs. beginners who are not programming using those apis have > no need for it. as such we have nothing else released that is anything OTHER > than those libraries and apis (well released as in alpha/beta). so that is our > only content. your problem seems to be that we just have a lot of content and > thats confusing to "newbies" because they only think of e as e - one thing. > its > all enlightenment. we should stop doing libs and just release enlightenment. > you have to use the wm too. and you get 50 libs. actually lets get rid of > that. thats confusing. lets make it 1 libefl. less confusing. > > fact is - it's a learning curve. that's reality. we have things split up for > our various reasons and thus yes.. people have to deal with that split. if you > don't know what evas does you have no need for the evas docs, or the evas > download button. you are not after evas. you have no idea what you are after > yet. thats what things like "about" are meant to help. to let you know what we > have and what may interest you depending what you are after. <joke>that's good, we keep getting consulting and training requests</joke> >> >>> = 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 :-) > > keep them there. we already have too many places for css/templates etc. etc. > to > change. don't make it worse. > >> >>> == 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. > > we used to have that. it was hopelessly maintained and empty. the entire page > per "technology" is over in the wiki. even that is hopeless too. the about > page > just summarizes it brochure-style. so we create another problem? >> > 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. > > that is what the wiki pages for elm, evas, eet, etc. etc. are for - thats why > they are all linked to. i moved the content over to there long ago, now you > want to move it back. but at the same time you propose moving other stuff out > of the main pages to the wiki entirely - i agree with the majority of it, but > it needs to be over in the wiki first before it gets nuked from e.org main. The sole purpose to move it back is to unify. From a single place you get the short description, docs, bugs and even download. >> >>> 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. > > technology page is the about page. its the same thing. just it doesnt go > breaking it up into sections. by your same argument how will someone know they > want evas? its just a technology section. the about page is meant to be a > summary of what is there and pointing you to the pages per piece of tech - > over > in the wiki. sure - a chunk of contribute page could be over in the wiki. i > don't see what you will do with docs other than what's there - it has links to > all the auto-generated docs we have (doxygen) and then some of the wiki -it > could expand and link to more. Raster, the problem is that you're looking at it from your own point of view. Find out a random EFL newcomer and see him using that website. Again, you KNOW where things are. You remember them all. That way you can even write the whole page in binary and you'd find stuff. For a multitude of reasons I introduce new people to EFL. From possible clients, to FOSS conference attendees, to university students and even new employees. If I'm not directly with them, those assigned to be always report back the same perceived problem: we confuse people, they get scared and uninterested easily. We must change to be more receptive with baby steps. Damn, contrast our website to Étoilé (http://etoileos.com/). Do a test, find some people, show both websites and ask around which did they like most, request an information about that website and watch people trying to get them. -- 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
