Re: [boost] Boost Library Incubator recommended by steering committee

Subject: Re: [boost] Boost Library Incubator recommended by steering committee
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-06-18 17:21:17

Klaim - Joël Lamotte wrote
> On Wed, Jun 18, 2014 at 5:29 PM, Robert Ramey <

> ramey@

> > wrote:
> 
>> >  - the library list by category is empty for me (I see a page with
>> header
>> > and all the theme but no content);

It's not a mistake - its a stub.  I haven't done it yet.  It didn't seem
urgent since
there are only 6 libraries submitted so far.  And it's a somewhat painful
exercise.

>> >  - if I click on a library name in the alphabetical library list, I end
>> up
>> > in a "Library Submission" page which have all the fields pre-filled
>> >    with the library information but still modifiable. It is not clear
>> to
>> > me
>> > if this is a voluntary hack to display these info without having
>> >    to implement another page or if it is just a bug and it should have
>> > been
>> > another page. In any way; the "Library Submission" title
>> >    and the writable fields makes it seems buggy.
> 
> Ok then my suggestion to fix the perception with minimal efforts would be:
>   when the reader is not the author (read-only access to the page)
>  1. lock all fields in read-only mode (so that it's visible/clear and
> people can't write into them at all);
>  2. remove the "Library Submission" title or replace it by something else
> ("Candidate Library?")
>      (for clarity that this page is not intended to be a library
> submission
> form for the reader to fill)

I took another look at this - and damn you're right.  The library pages
shouldn't be editable by anyone other than the submitter.  Users can't
do anything because they don't have a "submit" button.  But clearly
this is confusing.  Thanks for pointing this out.

> I think these changes should be enough, but I'm not sure if it's easy to
> implement from your current code.
> If it was just some javascript I could have helped but I think it's better
> done on the server side (where the access rights is known).

again thanks for pointing this stuff out.  It's incredibly hard to see
on your own.

>> again - I love the way the boost documentation adjusts to the current
>> window size.  I think ALL web pages should work this way.  I just
>> don't see anyway to reconcile these points of view.
>>
> 
> I don't see a way either and therefore I will not argue more on this, it's
> not useful a the moment.

btw - up until very recently, I always had my display in "portrait" mode.
I always found this easier for me as the format of everything is more
like an A4 sheet of paper - and the lines don't get too long.  This has
strongly influenced my distaste for web page text which either 
stretch the whole distance across the screen or are truncated to some
arbitrary width - which are all different.  Now I have a giant screen
and I usually set my browser to a "portrait" format which leaves 
either the right/left part of the screen free - which is what I'm used to.

And this comment touches upon an more fundamental point.  There are
two ways of going about something like this.

a) start a discussion and let everyone express their ideas.  Debate these
ideas and come to some consensus.  Then convince someone to do the
actual work.

b) Just do it.  Make sure there is a unifying consistent concept and try
to sell the concept after the fact.

As you can see, I chose b) above.  Can you imagine what this process
would have been like had I chosen a) above?  Of course you can - we'd
still be discussing  it.  Now we have something which implements a clear
purpose (Automate the boost review process without changing it's
fundamentals)
in an expedient way.

So we actually have something that
a) represents a concrete proposal rather than a speculative abstraction.
b) which is easier to talk about and dispute in a rational way.
c) which can (hopefully) evolve into something that is really useful.

Then there is the implementation.  My criteria was to implement something
complete enough to represent the concept with the minimal amount of 
effort.  The result is that we actually have something we can use before
the original idea becomes obsolete.

So far - I regret nothing.

Boost could learn from this.

a C++/CMS would be a very interesting application - and of course a very
large
one if it's to compete with wordpress and others.  But use of native code in
this
context would likely make a measurable contribution to lower global energy
consumption.  I would like to see someone (else) do this.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-Library-Incubator-recommended-by-steering-committee-tp4663966p4664305.html
Sent from the Boost - Dev mailing list archive at Nabble.com.