On 20 January 2014 16:49, sebb <seb...@gmail.com> wrote:

> On 20 January 2014 15:14, jan i <j...@apache.org> wrote:
> > On 20 January 2014 16:01, sebb <seb...@gmail.com> wrote:
> >
> >> On 20 January 2014 13:38, jan i <j...@apache.org> wrote:
> >> > Hi.
> >> >
> >> > Our homepage needs a workover, I like the graphic and would not change
> >> > that, but I propose the following changes:
> >> >
> >> > 1) "browse labs" is changed, so labs are grouped according to their
> >> status.
> >> >     - each lab get 1 line with a link to a human readable version of
> the
> >> > DOA and 1 line with the timestamp of the last commit.
> >>
> >> s/DOA/DOAP/ ??
> >>
> > thx.
> >
> >>
> >> Good idea to autogenerate the contents from the DOAPs.
> >>
> >> >    - each lab get a link to their "own" homepage (runs off the labs
> vm)
> >>
> >> That seems like more work for the lab to maintain (and additional
> >> skills may be needed).
> >> Would it not be better to generate the pages from a specific directory
> in
> >> SVN?
> >> Labs already need to maintain SVN.
> >>
> >
> > I am not sure its extra work, url would be
> > http://labs.apache.org/{labname}. The labs committers could change it
> > directly on the vm.
>
> An existing labs user must already be familiar with SVN and how to
> commit changes to it.
> However, they will do this on their own host system using tools with
> which they are alreasedy familiar.
>
> This is very different from logging on to a different system (how do I
> login? logout?), finding the correct file to update, using the strange
> new editor etc.

huh ? using svn does not you give a editor or help you find the correct
file.

if the committers work on the vm, they will normally use svn, so no
difference to working on a foreign system. As long as the page ends in svn
so it can be picked up for the URL I dont really care what they use.

> But I agree it would be more automatic to pick up the changes from SVN (we
> use cms today, that could do the job). If we require a naming standard,
> such a script would be easy.
>
>
>
>> > 2) change timeline on front page to include number of project that
>> > committed in the period.
>>
>> Good idea.
>>
>> > 3) Add a whiteboard page, where ASF committer can offer their help
>> > (especially knowledge) and labs projects can ask for specialists. The
>> > whiteboard page might be of interest for incubator, that has the same
>> > problem (and no solution).
>>
>> The page would have to be protected against spam, so editors would
>> need to be allowed to post (or authorised in some way).
>> Would it be sufficient to use a Labs Wiki for this?
>>
>
> A labs wiki would actually be a better idea. I was simply not sure if it
is
> overkill.

Well maybe, but why reinvent the wheel?
> I suspect it's not trivial setting up and maintaining a secure whiteboard.
>
No but it might be easier to use than confluence wiki. My only real concern
with wiki is the ease of use.

rgds
jan I

>
> > A labs wiki would also give the labs a place to easy exchange ideas.
>
> As does the mailing list.
>
> But for some discussions and collaboration, a Wiki is better.
>
> > rgds
> > jan I.
> >
> >
> >> This would have the advantage that changes are notified to a mailing
> list.
> >> [The whiteboard ought to do the same]
> >>
> >> > At this point in time we cannot change the bylaws text, that will come
> >> in a
> >> > second pass.
> >> >
> >> > I volunteer to make the changes.
> >> >
> >> > rgds
> >> > jan I.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
> >> For additional commands, e-mail: labs-h...@labs.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
> For additional commands, e-mail: labs-h...@labs.apache.org
>
>

Reply via email to