trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <pierre.sm...@gmail.com>
Subject Re: Anyone working on putting up a website at trafodion.incubator.apache.org and....
Date Fri, 10 Jul 2015 22:27:36 GMT
As said elsewhere in this ml, the ml manager solution of the ASF doesn't
forward attachments to mailing list.

Best thing to do is to open a JIRA issue and have it attached there.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Jul 11, 2015 at 12:21 AM, Alice C. <alchen@apache.org> wrote:

> Hello Venkat,
>
> I cannot see your picture.  Could you please upload it somewhere like
> Google Drive/Dropbox and post a link?
>
> Cheers,
> Alice
>
> > On Jul 10, 2015, at 3:10 PM, Venkat Muthuswamy <
> venkat.muthuswamy@esgyn.com> wrote:
> >
> > Hi Alice,
> >
> > I wasn't sure if you were continuing work on this. I started looking
> into maven and fluido based site and attached is a picture.
> > You and I can sync up on this...
> >
> >
> >> On Fri, Jul 10, 2015 at 2:52 PM, Steve Varnau <steve.varnau@esgyn.com>
> wrote:
> >> Yes, looks like a great start, Alice.  Once this is in, then everyone
> can
> >> have a framework to add new info.  It'd be great if you can give folks
> >> guidance (on wiki?) on how to test out changes to the web site.
> >>
> >> -Steve
> >>
> >> On Fri, Jul 10, 2015 at 2:37 PM, Pierre Smits <pierre.smits@gmail.com>
> >> wrote:
> >>
> >> > Carol, all,
> >> >
> >> > Any project/podling under the umbrella of the ASF can, independently
> of
> >> > others, decide what kind of information and where. Some only show
> technical
> >> > stuff, others mainly show project info. Others have a more nuanced
> >> > approach. I like this setup: http://couchdb.apache.org . It starts
> with
> >> > the
> >> > product, then the invite to participate.
> >> >
> >> > You have to take into consideration that the whole (website and wiki,
> JIRA
> >> > and Git) is or should be targeted at the entire spectrum of potential
> and
> >> > existing adopters, potential and existing contributors. That is a very
> >> > diverse public. And the potentials out there come from (often) a
> triggered
> >> > business interest.
> >> >
> >> > It is a balancing act on a tight-rope. But you have to keep in mind
> that
> >> > changes to web pages requires commit privileges. Changes to wiki pages
> >> > doesn't require that strict ruling.
> >> >
> >> > As for referencing from website to wiki and vice versa, that should
> be done
> >> > as much as possible (when and where suitable). Better done that way,
> than
> >> > creating multiple pages at various places that require upkeep.
> >> >
> >> > Best regards,
> >> >
> >> > Pierre Smits
> >> >
> >> > *ORRTIZ.COM <http://www.orrtiz.com>*
> >> > Services & Solutions for Cloud-
> >> > Based Manufacturing, Professional
> >> > Services and Retail & Trade
> >> > http://www.orrtiz.com
> >> >
> >> > On Fri, Jul 10, 2015 at 8:34 PM, Carol Pearson <
> carol.pearson234@gmail.com
> >> > >
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I've spent some time looking at the Apache wiki and looking at what
> other
> >> > > Apache projects have as their wikis as well, and the distinction
> between
> >> > > those and the project websites, then doing what Dave did above -
> asking
> >> > > what information needs to go at which location, how do we go about
> the
> >> > > separation etc.
> >> > >
> >> > > It seems to me that the distinctions on content on the various
> Apache
> >> > wikis
> >> > > versus websites is pretty clear. The wikis are mostly oriented
> toward a
> >> > > brief product introduction  (Pierre, I saw your comment on the
> current
> >> > wiki
> >> > > that what we have there now really belongs on the website - were you
> >> > > suggesting that we have a 2-3 sentence intro and a pointer to the
> website
> >> > > on the wiki front page?)  and then quickly into the welcomes and
> how-tos
> >> > > for contributing.
> >> > >
> >> > >  Some Apache wikis have more information about the product as well,
> but
> >> > > others put that entirely on their websites.  For example the Ambari
> wiki
> >> > > has quick start for setting up Ambari, troubleshooting, etc., which
> is
> >> > not
> >> > > strictly developer/contributor oriented, and info about features
> that are
> >> > > not yet part of the project, for example.  The Qpid Wiki is very
> sparse.
> >> > > Bigtop is pretty active and shows a balance focused mostly on
> mechanics
> >> > and
> >> > > development while the website shows a broader, more informational
> focus.
> >> > > Not quite the same domain but maybe that's an illustrative model?
> >> > >
> >> > > I note that in the list of Spaces, there is no description for
> Apache
> >> > > Trafodion, so we should add that. I also note some inconsistencies,
> where
> >> > > some things have Apache in front of them and some don't, making it
> harder
> >> > > to search alphabetically - I couldn't find Qpid, for example, until
> I
> >> > > looked under Apache Qpid.
> >> > >
> >> > > On the mechanics of website building, I think it's a good idea to
> have it
> >> > > under control and built regularly.  That allows fallback to previous
> >> > > versions, etc., which can be a problem for websites, and as we
> extend
> >> > with
> >> > > different releases, we have the appropriate website versions as
> well.
> >> > But
> >> > > it also adds a burden on our current set of committers because
> those are
> >> > > additional changes that need to be approved.
> >> > >
> >> > > -Carol P.
> >> > >
> >> > > On Fri, Jul 10, 2015 at 11:09 AM, Pierre Smits <
> pierre.smits@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > May I suggest the following as a starting point:
> >> > > >
> >> > > >
> >> > > >    1. Have marketing and promotional pages (the more static ones)
> in
> >> > the
> >> > > >    website, this means for the product  the description,
> documentation
> >> > re
> >> > > >    latest available release, intended use etc, and for the project
> >> > > > high-level
> >> > > >    outlines and references to wiki pages
> >> > > >    2. Have community internal and other frequently changed pages
> in the
> >> > > >    wiki, but also release notes (copy-paste from JIRA), etc.
> >> > > >
> >> > > > I find JIRA issues a good thing to track assignment and progress,
> even
> >> > > for
> >> > > > websites. Just mentioning stuff in a mailing list could lead
to
> >> > > > forgotten/not done, due to the high pace of overcrowding.
> >> > > >
> >> > > > Best regards,
> >> > > >
> >> > > > Pierre Smits
> >> > > >
> >> > > > *ORRTIZ.COM <http://www.orrtiz.com>*
> >> > > > Services & Solutions for Cloud-
> >> > > > Based Manufacturing, Professional
> >> > > > Services and Retail & Trade
> >> > > > http://www.orrtiz.com
> >> > > >
> >> > > > On Fri, Jul 10, 2015 at 6:31 PM, Dave Birdsall <
> >> > dave.birdsall@esgyn.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > At the moment I don't think anyone is working on it. Alice
Chen
> was
> >> > > doing
> >> > > > > most of the work there but was redirected, so some regrouping
is
> >> > > needed.
> >> > > > >
> >> > > > > To get that thought process going, I'll think out loud a
bit, a
> >> > mixture
> >> > > > of
> >> > > > > statements and questions. Comments welcome.
> >> > > > >
> >> > > > > Before we went Apache, we had a single web site,
> www.trafodion.org
> >> > > > (still
> >> > > > > out there). That had a variety of content, broken down into
the
> >> > > following
> >> > > > > areas:
> >> > > > >
> >> > > > > 1. Understanding the software -- contained a description
of
> >> > Trafodion's
> >> > > > > architecture (in some detail), lists of recently released
> features,
> >> > and
> >> > > > > roadmaps
> >> > > > > 2. Using the software -- contained information about download
> and
> >> > > > > installation (including a pointer to a downloads page),
and high
> >> > level
> >> > > > > description of how to use the software (e.g., how to start
a
> >> > Trafodion
> >> > > > > instance)
> >> > > > > 3. Contributing -- detailed descriptions of the mechanics
of
> >> > > contributing
> >> > > > > to Trafodion (this has been updated with Apache practices,
so
> it is
> >> > > > > current)
> >> > > > > 4. Community -- description of governance, and lists of
people
> who
> >> > were
> >> > > > > currently working on Trafodion and their areas of
> specialization, and
> >> > > > > community events
> >> > > > > 5. Documentation -- the SQL manual and related documentation
> >> > > > > 6. Other stuff, e.g. videos and an FAQ
> >> > > > >
> >> > > > > In the Apache world, Trafodion itself is on a course to
have
> two web
> >> > > > sites:
> >> > > > > http://trafodion.incubator.apache.org/ and a wiki,
> >> > > > >
> >> > > >
> >> > >
> >> >
> https://cwiki.apache.org/confluence/display/TRAFODION/Apache+Trafodion+home
> >> > > > > .
> >> > > > > First question that pops into my mind is, how should content
be
> >> > broken
> >> > > > down
> >> > > > > between the two?
> >> > > > >
> >> > > > > Alice's idea for http://trafodion.incubator.apache.org/
was
> for it
> >> > to
> >> > > be
> >> > > > > built as part of the daily build from the source repository.
One
> >> > > benefit
> >> > > > of
> >> > > > > that is that the workflow for changing the web site was
> identical to
> >> > > that
> >> > > > > for changing Trafodion code itself. It would be subject
to the
> same
> >> > > > review
> >> > > > > standards and go through continuous integration. Updating
the
> wiki of
> >> > > > > course uses a different workflow and has a different permissions
> >> > > > structure.
> >> > > > >
> >> > > > > And of course some of the material on www.trafodion.org
will no
> >> > longer
> >> > > > be
> >> > > > > relevant in the Apache world so it goes away, or is replaced
> with
> >> > > > pointers
> >> > > > > to general Apache web sites.
> >> > > > >
> >> > > > > The current state of things seems to be:
> >> > > > >
> >> > > > > 1. Understanding the software -- none of this is on Apache
yet;
> the
> >> > > stuff
> >> > > > > on the old wiki is up-to-date
> >> > > > > 2. Using the software -- none of this is on Apache yet;
the
> stuff on
> >> > > the
> >> > > > > old wiki is up-to-date
> >> > > > > 3. Contributing -- general high level info + a list of current
> >> > > > contributors
> >> > > > > is present on the Apache wiki (
> >> > > > >
> >> > > >
> >> > >
> >> >
> https://cwiki.apache.org/confluence/display/TRAFODION/Apache+Trafodion+home
> >> > > > > ),
> >> > > > > while detailed instructions about navigating Trafodion
> development
> >> > > > > infrastructure (git, Jenkins and the like) are up to date
on
> the old
> >> > > wiki
> >> > > > > www.trafodion.org.
> >> > > > > 4. Community -- future events has a page on the Apache wiki;
> past
> >> > > events
> >> > > > > are on the old wiki. Governance material on the old wiki
is
> obsolete
> >> > as
> >> > > > it
> >> > > > > is pre-Apache.
> >> > > > > 5. Documentation -- none of this is on Apache yet; the manuals
> are
> >> > > > > up-to-date with respect to the last release of Trafodion
but do
> not
> >> > > > contain
> >> > > > > new features developed since (which is an additional concern)
> >> > > > > 6. Other stuff -- none of this is on Apache yet
> >> > > > >
> >> > > > > Looking at this list: Governance stuff should go away, replaced
> by
> >> > > > pointers
> >> > > > > to the appropriate ASF pages. As to the rest...
> >> > > > >
> >> > > > > Getting back to the question of which site should hold what
> content:
> >> > > I'd
> >> > > > > like to suggest that technical content (documentation,
> architectural
> >> > > > > description, and the like) should be on the
> >> > > > > http://trafodion.incubator.apache.org/ web site, and go
> through the
> >> > > same
> >> > > > > workflow as code does.Information about contributing and
> community,
> >> > > along
> >> > > > > with "other stuff" seems like appropriate content for the
wiki.
> My
> >> > > > > rationale is that the technical content should reflect the
code
> and
> >> > > > > therefore be in sync with it. What do others think?
> >> > > > >
> >> > > > > A procedural question: Once we get consensus on what goes
> where, the
> >> > > next
> >> > > > > step seems to be to structure a work program around it.
Are
> JIRAs the
> >> > > > right
> >> > > > > mechanism to do this? A JIRA sounds right for the stuff
that
> goes
> >> > > through
> >> > > > > normal workflow. Would it be appropriate to use a JIRA for
the
> wiki
> >> > > site
> >> > > > as
> >> > > > > well?
> >> > > > >
> >> > > > > Welcoming thoughts and further discussion,
> >> > > > >
> >> > > > > Dave
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > On Fri, Jul 10, 2015 at 8:14 AM, Stack <stack@duboce.net>
> wrote:
> >> > > > >
> >> > > > > > Anyone working on the website? This don't look too
good as
> home
> >> > page:
> >> > > > > > http://trafodion.incubator.apache.org/
> >> > > > > >
> >> > > > > > Yours,
> >> > > > > > St.Ack
> >> > > > > >
> >> > > > > > On Mon, Jun 29, 2015 at 3:20 PM, Stack <stack@duboce.net>
> wrote:
> >> > > > > >
> >> > > > > > > I updated our status page
> >> > > > > > > http://incubator.apache.org/projects/trafodion.html
> >> > > > > > >
> >> > > > > > > Anyone on the website?
> >> > > > > > >
> >> > > > > > > We going to make a new logo with Apache in it?
> >> > > > > > >
> >> > > > > > > St.Ack
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> -Steve
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message