Hi Kay, all,
Kay Schenk schrieb:
Hi Ingrid!
Ingrid Halama wrote:
Hi Kay, all,
Kay Schenk wrote:
Hello *,
I made some rather minor tweaks to my revision at
http://website.openoffice.org/tryouts/Kay/projects/
Your work is so much an improvement to what we have now :-), great!
Are there any objections to go online with that?
Maybe a mail to all project leads could assure acceptance?
Why don't you post on the project lead's list about it?
hmmm...thanks for the encouraging words...I intned to do more work on
this this evening. After this weekend, I probably can not do much work
on it for the next week or so. see below...
Some things to mention. I think it's rather important NOT to get
topics all garbled up together. With this in mind, I DID NOT put Kay
Ramme's lovely graphic about how components integrate on this page.
And...although there is some merit in devling right in to development
type issues, this isn't really what this page is for, is it?
I would agree.
I also share Clyties opinion that the project leads don't need to be
listed here. The provided content about the projects should speak for
itself. If that is not sufficient the next step are the public forums
( mailing lists etc.). Ideally there should be only very rare cases to
contact the project leads via private mail, or?
The only value I can see to keeping the project leads is it's a quick
way for someone to just send off an e-mail to him/her. Yes,
theoretically, they should be able to do this by going to the actual
project page, but then you're into extra clicking. The drawback to
having them here, of course, is that we need to keep on top of updates
to this. Ah, for a DB interface to some of our pages! :{
There is quite a difference between developing and other projects in
this regard:
- Developer think of directly contacting the project lead who should
know about the right person to do a specific job (especially if there
are groups of developers working jointly together).
- All the other projects don't have this hierarchical structure. Tasks
are solved (or not) by asking on the mailing list for someone willing to
do the job. If there are people responsible for specific subprojects (or
tasks) they have a look at the list and raise their hands if they think
the task belongs to them. Sometimes they are mentioned as contact people
on the project's website, so they can be addressed directly.
In any case, if someone doesn't know about the project's structure, it
is much better (IMHO) to send him/her to the project's main page with
informations about the structure - and a direct link to the project leads.
So it's just one click more for people interested in nothing but the
eMail address of the projects lead - everybody else will be able to get
more (hopefully relevant) informations on the project's site, so the
direct mail might become unnecessary...
In addition is there any use to have the short name/description of the
projects here?
Probably not. I was wondering about this myself. I think removing the
short names probably would do no harm at all, except that this is how
things show up when use use the "project" servlet. But I'm neutral on
this suggestion.
They give a hint about cvs access and the according mailinglist names.
But the former really is already a deep development detail and the
latter is not so obvious that the information about the short name is
sufficient to get the complete mailing list name. So when there is no
other use for it I would suggest to skip that column also.
This information than should be provided on each project page.
I'd mention the full project's name (<short_desc>.openoffice.org) here,
perhaps in parentheses in the first column, because we point people to
mailing lists and project's pages by using this name. ("Ask on
[EMAIL PROTECTED]", "Did you have a look at the dba.OOo pages?")
If you don't know which project is hidden behind an acronym like udk, ui
or l10n, you will not be able to reach the projects pages.
What in contrast I would like to add are the product names to all
projects that are directly related to the products - Calc, Writer,
Impress, Draw, Base, Chart, Math ... . I think this is important as
often website users do search for keywords instead of reading the
whole text. So this important keywords should be on the project page.
OK--I think this is a good idea and I'll see what I can come up with.
Unfortunately, I feel my knowledge might be a bit limited for some things.
It's quite the same I proposed a few days ago - but I'd add the
application icons to the names. They would be easily discovered and
recognized by any user...
Also the heading 'Products' raises the expectation to find the product
names here.
Maybe we can introduce a column for that? Or at least offer the
product names all in the same style for each project? What is tricky
and confusing is that some projects do host more than one product.
E.g. the Word Processing project does host Writer and Math. The
Graphic Applications project does host Impress, Draw and Chart. Some
historically grown structure which continues to confuse users ... . In
the long run I think it would be better to split those overloaded
projects.
Not being a developer, I don't know about a possible common code basis
of those (sub)projects. I'd like to replace Word Procesing by Writer and
Math, Graphics by Impress, Draw and Chart - keeping the present projects
while introducing the new ones will cause some confusion (or even
frustration?) in "normal" contributors.
Perhaps these common parts may be covered by framework, too?
Probably, but I can't do that here. This is up to the OOo project leads.
Also, in contrast, I think some of them could be combined, like the Q&A
project with Documentation. To end users, these two things are really
tied to support.
I don't know about a Q&A (meaning "Question & Answer") project - FAQ are
part of the main site, without any project. They might become part of
the documentation project.
... QA project ("Quality Assurance") is only partially covered by
support, as I wrote before, it's much more part of developing IMHO.
Just some tenths of a cent (similar to the petrol station ;-)
Best regards
Bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
