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 > >