Re: [E-devel] web site contents

[Carsten H. (T. R. <ra...@ra...>]

On Mon, 8 Nov 2010 21:36:27 -0500 Jesse Charbneau <je...@th...> said:

website doesnt need any amazing web skills. it just needs content shuffling.
there's. so you don't really need those. the site is in svn - the rest is on
the wiki (trac). again - wiki markup. :) if you can figure out why trac does
the crazy shit it does though (like lose attachment db entries or simply have
new accounts not work etc.)... that would be awesome though - your skills may
be useful there.. but trac is python + mysql. so it depends if that's your
thing or not.

> 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.

that's always good.

> 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... :)

> > 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 <ra...@ra...>
> > wrote:
> >> On Mon, 8 Nov 2010 18:32:54 -0200 Gustavo Sverzut Barbieri
> >> <bar...@pr...> 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.

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.

> > 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.

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.

> >   -  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.

> > 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.

> > 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.

> > 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.).

> >    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.

> >>> == 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.

> >>> 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.

> >>> 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.

> >>> 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.

> >>> == 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.

> > 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.

> >>> = 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.

> > 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. 

> >>> 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.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...