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).
== 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!
== 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.
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...
Building: not something for brochure. Replicates what's in DOWNLOAD
and svn.enlightenment.org.
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"
- Coding Style: need to be objective. Just say one should respect
existing style in that file otherwise patches will be rejected. Link
to trac with actual definition of coding style and examples,
explaining of uncrustify and configuration for various editors --
again, in TRAC.
- 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.
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
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.
== 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.
== 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.
= 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
== 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...)
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.
--
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
