On 20 January 2014 20:13, jan i <j...@apache.org> wrote: > 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.
No, but as I already wrote, the user will be using their own familiar host system tools for navigation and editing. And the user host system is likely to be GUI-based, whereas I imagine the VM will be command-line access only (at least for the guests). > 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. See above; SVN is not the main issue here. >> 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. I assumed we would use the MoinMoin Wiki, which is fairly easy, and already used extensively in the ASF. Confluence is not as well known (and seems to be a lot harder to 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org For additional commands, e-mail: labs-h...@labs.apache.org
