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
