Re: W3C Solid Community Call

On Thu, Mar 28, 2019 at 10:58 AM Eric Prud'hommeaux <eric@w3.org> wrote:

> On Wed, Mar 27, 2019 at 07:12:32PM +0100, Melvin Carvalho wrote:
> > On Wed, 27 Mar 2019 at 18:43, Melvin Carvalho <melvincarvalho@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Wed, 27 Mar 2019 at 18:23, Mitzi László <mitzil@inrupt.com> wrote:
> > >
> > >> Hi W3C Solid Community Group,
> > >>
> > >> You can find the final agenda [1] and dial in details [2] for the call
> > >> tomorrow at 1400 CET.
> > >>
> > >
> > > "proposal to move specs to github/w3c-solid"
> > >
> > > This proposal is problematic, in a general sense.
> > >
> > > When I spoke to Tim about starting this group, we did it because we
> didnt
> > > have a place (ie mailing list) for threaded conversations, of a
> technical
> > > nature.
> > >
> > > There is an expanse of the remit here, which im not opposed to, ie to
> help
> > > incubate all the solid specs.  I think it's actually a good idea, it is
> > > however, a different idea from what I put down when I started the
> group.
> > >
> > > But in practice, a mandate needs to come explicitly from Tim, even
> better
> > > if he were to join the group (so that he can read mailing list
> discussion),
> > > and cannot be via proxy.
> > >
> > > Tim needs to say what he wants to be put under the aegis of the CG, at
> > > least initially.
> > >
> > > Overall what we require from the specs is a period of stability.  If
> this
> > > group can help to ensure that, I think that's going to be a plus for
> solid.
> > >
> >
> > My constructive suggest is as follows :
> >
> > From my experience, It normally takes a W3C, or any other group
> actually, 6
> > months to find its feet.  You will get initial interest, and then
> depending
> > on the cadence of the calls, people will start to drop off and you will
> be
> > left with a few people that attend calls regularly
> >
> > In parallel to this groups tend to find a governance system which is
> > basically unanimous common sense decisions are taken most of the time.
> >
> > What I would suggest is that this group for 6 months, or even better
> until
> > end of the year, incubate proposals, but with a lock on not removing
> > anything that may be in use.
> >
> > By this time we may have a relatively stable server and a bunch of
> apps.  I
> > think the bulk of the work in the group will be oriented towards new
> > proposals, new shapes, design patterns and things like naming consensus.
> > The better proposals then get promoted further.
>
> I totally agree about the start-up cost of W3C groups, and I would
> strongly caution against starting one. When you do, you end up making
> a contract with the W3C members that you're going to start with X and
> produce Y in Z time. It's much more efficient to start a working group
> once you've already got a solid design, tests and multiple
> implementations that pass those tests.
>
> Given the number of repos in github.com/solid, I do think it could be
> helpful to separate the specs from the implementations.


+1 to separating the specs from the implementations


> Right now,
> they're sort of awash in a sea of repositories (75) and we want to
> make it as easy as possible for folks to find the repos to submit
> issues and PRs.
>
> We wouldn't have to move them to github.com/w3c but it kind of makes
> sense; folks are already used to looking there for W3C Community Group
> products and it wouldn't require any interaction with W3C so those
> group start-up costs go to 0. The cost to us is:
>
> 1 that someone has to click a couple buttons on github
>
> 2 we have to change the upsteam repo wherever we have it checked out.
>
> 3 we should update links to anything we move.
>
>
> > >> Mitzi
> > >>
> > >> [1] https://www.w3.org/community/solid/wiki/Meetings
> > >>
> > >> [2]  https://zoom.us/j/121552099
> > >>
> > >>
> > >>
> > >>
>
> --
> -eric
>
> office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
> mobile: +1.617.599.3509
>
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
>
>