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