Seems that no response ... But don't care.
MY Practical Proposal:
Establishing CA Server in @apache.org
(For S/MINE, PGP etc.)
The Apache Software Foundation has numerous faxes or papers from all
of the committers at least, and they would be reliable. It's good idea for me
(and YOU)
to establish CA Center (Server) in apache.
Please use my (sponsorship) money for it.
Any thoughts?
Thanks
Tetsuya Kitahata kitah...@99.alumni.u-tokyo.ac.jp tets...@apache.org
-
Dear ASF PRC Members
#CC: commun...@a.o.
Message From Tetsuya Kitahata wearing #Sponsor HAT#
I am celebrating the 10th anniversary of the ASF and the success of
ApacheCon EU. I am sorry to respond late because of the additional
(personal) sponsorship things etc.
About the doap things, any kinds of progress at ApacheCon EU 2009??
Seemed that I could not see any progress... right?
As for doaps, attached file (doaps.tar.gz) contains some missing
doaps, so please use appropriately.
(Includes recent news item projects -- Zookeeper, Mailet Base,
CXF, PyLucene, Buildr, CouchDB etc. -- enhance, edit plz.
I am afraid I could not describe correctly)
I think that evangelizing this project (DOAP project) is ought to
be more efficient. People (developers) can not find right project
for their products etc. in apache.org now. Please take it seriously.
By the way, I have a translation website of projects.apache.org
at http://projects.terra-intl.com/ (Japanese)
If possible, linking from http://projects.apache.org would be very
impressive for japanese apache lovers. Plz add.
# Maintained completely by doaps.
Obrigado,
-- Tetsuya Kitahata tets...@apache.org
Tetsuya - thanks for the note. I'm sending this just to prc@ since both
Jim and I are on that list.
Tetsuya Kitahata wrote:
As usual, corporate sponsor won't speak to PRC
directly as a sponsor. Of course, I know that Apache
should not be a slave of sponsors. What I would like to
talk is not such a kind of thing. Please understand.
Yes, I agree that the ASF should not be influenced or controlled by
sponsors (slave). However we (the ASF, and in particular the PRC) do
want to be responsive and open to hearing what our sponsors are
interested in and thinking about. So please do email prc@ with your
thoughts when wearing your #sponsor hat#!
1. Congratulations on PRC Fundraising Committee. Both working
together would be beneficial to the foundation I believe.
Plus, personally I think that this Committee also have Communication
Committee. -- For example, jobs@, community@, woman@ management etc.
and evolved to Public Relations, Communications and Fundraising
Committee.
(If Communications means internal and exrternal, Public Relations
would
be needless, maybe)
Yes, the PRC (Public Relations Committee) is basically in charge of most
of those areas on the broad scale. Overall communication with the
public should be what the PRC manages, however we may not have always
formally taken charge of the various email lists and other topics. The
areas that the PRC clearly owns, and how the PRC sets policy and goes
about using then is still being defined over time.
Several other PRC members and ASF members have been thinking about how
we do outreach - how we, as an open source and software organization,
can more actively attract developers and educate the public and
businesses about open source best practices. Here on prc@ is probably
the best place to work on those kinds of subjects.
2. Please encourage the doap files to be created more. Plus, I
suppose doap files should not be maintained by each PMC,
rather in one repository they should be put, I hope. Simple reason.
When I find error in doap, I must put the opinions on each dev list,
it is very painful for each other.
(Sometimes it happened in the past: see attached file for example)
#DOAP# repository would be OK. (all committers can edit) -- and
current ones (in svn repositories in each projects) to be batch renewed
daily or hourly.
One of the things I hoped to do over ApacheCon next week is to create
and update more project's DOAP files to ensure we have complete
coverage. In many cases if we send a patch to the dev@ list for a
project, I expect they'll check it in for us.
I disagree that the DOAP files should be in a central repository. The
best place to create and store these is in the individual project
repositories, since the individual projects really need to be
responsible to keep them updated. Part of the problem with poor
maintenance of the DOAP files is that projects don't realize how much of
a strategic value to the ASF overall they can be.
3. I had thought that the announcements at annou...@apache.org how
to be more polished.
I agree that we'd like to have more polished
