Re: Speakers and booth support needed at the next Codemotion events

[Mike Yuxxxp]

On Thu, Oct 18, 2018, 11:11 PM Santiago Gala 
wrote:

> I will be able to stay early afternoon.
>
> Let me know if it works for you, so that I book the date .
>
> Regards
> Santiago
>
> On Mon, Oct 8, 2018 at 2:42 PM Piergiorgio Lucidi 
> wrote:
>
> > It seems that we have a first schedule of Codemotion Madrid:
> > https://madrid2018.codemotionworld.com/conference/
> >
> > Ignasi should talk from 15:10 to 15:50 on 30th November.
> > @Santiago, do you think that you can stay at our booth during the early
> > afternoon?
> >
> > Please let us know.
> > Thanks.
> >
> > Cheers,
> > PJ
> >
> > Il giorno mer 3 ott 2018 alle ore 19:41 Ignasi Barrera 
> > ha
> > scritto:
> >
> > > I think the schedule for Madrid hasn't been published yet, but the only
> > > thing required, if possible, would be to be at the Apache booth during
> my
> > > talk :)
> > >
> > > On Wed, Oct 3, 2018, 19:10 Santiago Gala 
> > wrote:
> > >
> > > > Sorry for jumping in so late, but I think I might be in Madrid those
> > > dates
> > > > and might help.
> > > >
> > > > I'm roughly 50% of my time in Madrid and 50% in London, with
> occasional
> > > > jumps to Valencia, so it is not yet fully sorted out...
> > > >
> > > > Tell me what would be needed.
> > > >
> > > > Regards
> > > > Santiago
> > > >
> > > > On Wed, Oct 3, 2018 at 9:37 AM Ignasi Barrera 
> wrote:
> > > >
> > > > > It would also be awesome if someone comes to the Madrid event too.
> > I'm
> > > > > staffing the booth there but I'm also giving a talk, so it would be
> > > > > great if someone could take care of it for the duration of my talk
> :)
> > > > > On Mon, 1 Oct 2018 at 12:00,  wrote:
> > > > > >
> > > > > > Hi PJ
> > > > > >
> > > > > > Thanks for the update. I'll contact you offline to discuss this.
> > > > > >
> > > > > > Thanks
> > > > > > Sharan
> > > > > >
> > > > > > On 1.10.2018 10:19, Piergiorgio Lucidi wrote:
> > > > > > > How could we make an order for a stock of stickers?
> > > > > >
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Piergiorgio
> >
>

Re: Speakers and booth support needed at the next Codemotion events

[Santiago Gala]

I will be able to stay early afternoon.

Let me know if it works for you, so that I book the date .

Regards
Santiago

On Mon, Oct 8, 2018 at 2:42 PM Piergiorgio Lucidi 
wrote:

> It seems that we have a first schedule of Codemotion Madrid:
> https://madrid2018.codemotionworld.com/conference/
>
> Ignasi should talk from 15:10 to 15:50 on 30th November.
> @Santiago, do you think that you can stay at our booth during the early
> afternoon?
>
> Please let us know.
> Thanks.
>
> Cheers,
> PJ
>
> Il giorno mer 3 ott 2018 alle ore 19:41 Ignasi Barrera 
> ha
> scritto:
>
> > I think the schedule for Madrid hasn't been published yet, but the only
> > thing required, if possible, would be to be at the Apache booth during my
> > talk :)
> >
> > On Wed, Oct 3, 2018, 19:10 Santiago Gala 
> wrote:
> >
> > > Sorry for jumping in so late, but I think I might be in Madrid those
> > dates
> > > and might help.
> > >
> > > I'm roughly 50% of my time in Madrid and 50% in London, with occasional
> > > jumps to Valencia, so it is not yet fully sorted out...
> > >
> > > Tell me what would be needed.
> > >
> > > Regards
> > > Santiago
> > >
> > > On Wed, Oct 3, 2018 at 9:37 AM Ignasi Barrera  wrote:
> > >
> > > > It would also be awesome if someone comes to the Madrid event too.
> I'm
> > > > staffing the booth there but I'm also giving a talk, so it would be
> > > > great if someone could take care of it for the duration of my talk :)
> > > > On Mon, 1 Oct 2018 at 12:00,  wrote:
> > > > >
> > > > > Hi PJ
> > > > >
> > > > > Thanks for the update. I'll contact you offline to discuss this.
> > > > >
> > > > > Thanks
> > > > > Sharan
> > > > >
> > > > > On 1.10.2018 10:19, Piergiorgio Lucidi wrote:
> > > > > > How could we make an order for a stock of stickers?
> > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > >
> > > >
> > >
> >
>
>
> --
> Piergiorgio
>

RE: Why are large code drops damaging to a community?

[ross]

+1 to both Shane and Myrle's input here.

The Apache Way is all about consensus building in order to maximize the 
potential for collaboration between partners. It is impossible to drive 
consensus within a community of individuals without enabling them to be a part 
of the whole process. Large code drops equate to a statement of "this is the 
way it is - my way or the highway". It is not a model for consensus building.

However, there are other models in which vendors define direction. Shane refers 
to these as "maintainer led" but I think that is too general, I prefer the more 
specific vendor led, because it is possible to have a consensus driven 
maintainer led project. 

Vendor led and the Apache Way are different models. One scales the community 
very well (Apache Way) and is ideal for building frameworks and/or components 
from which products are built. The other (vendor led) doesn't scale so well but 
is ideal for building highly focused products. The Apache Way maximizes the 
opportunity for cross-organizational collaboration and thus drives 
combinatorial innovation. Vendor led limits the scope of the collaboration but 
allows one to target a more clearly defined customer base.

The trick to success is ensuring that you are using the right model for the 
right parts of the open source ecosystem. There is no single model for 
governance of open source, success comes from understand when and how to apply 
different models to different parts of your software solution.

Ross



-Original Message-
From: Shane Curcuru  
Sent: Thursday, October 18, 2018 8:26 PM
To: Apache Community Development ; Apache Fineract 
Dev 
Subject: Re: Why are large code drops damaging to a community?

Myrle Krantz wrote on 10/18/18 7:18 AM:
> Hey all,
> 
> There are many forms of offlist development.  One form of offlist 
> development is working on large code drops in private and then 
> contributing them all at once.  Threshold size is probably arguable, 
> and varies by project; put that aside for the moment.  I've been 
> working on an explanation of how large code drops damage community and 
> code.  I'd love to hear your feedback.  I'm including my project and 
> the dev@community list in the hopes that people from other projects 
> also have a perspective.  Here it goes:

Thanks Myrle for an excellent writeup, including details of how large code 
drops harm Apache style open communities.  This is a great set of examples 
showing the "why" behind the ASF's requirement that the whole community be 
allowed to participate in *all* parts of a project's technical development.

The requirement for an open and consensus-driven development process at the ASF 
doesn't just impact the individual perspective - which you've covered in detail 
in your post.  More importantly, it impacts the whole
*community* ownership feeling of an Apache project.

This is a key difference I see between Apache projects and maintainer-led 
projects.  There are many examples of maintainer projects with issues, 
successes, whatever.  But they primarily focus on how a handful of maintainers 
are struggling to keep their project growing for the benefit of all their users.

The issue is the mindset of "maintainers".  An Apache project should have the 
entire community of contributors feeling like they have a stake in the project, 
that they can help build new ideas, and that they
*share* as a whole group the direction of the project.  While much of the 
actions are the same, my point is about the feeling of ownership.
It's not just a few "maintainers" driving things; it's *everyone* who's a 
committer (and hopefully soon, many of the contributors who get voted in).

Offlist development prevents this truly shared sense of ownership from 
developing, which is why it's prohibited for Apache projects.

...snip...
> Open source projects require transparency, not just as a moral value, 
> but as a pragmatic prerequisite for collaboration.  Offlist 
> development damages the community *and* the code.

More to the point, repeated significant offlist development will attract the 
attention of the ASF board, which may well take direct action to prevent that 
kind of behavior from happening going forward.  One advantage of the ASF's 
independent governance is that it can enforce the core open development model 
that's a key part of the Apache Way.

Note that I'm struggling to find where "offlist development is forbidden" is 
explicitly called out on the apache.org website, so pointers to existing places 
that *explain* this core concept and why it's important are appreciated.

My attempt to explain how open development works is here:

  http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24

- Telegraph your intent: email dev@ with your *ideas* ahead of time.
This allows feedback, encouragement, someone else to point out similar code is 
already over there, etc.

- Draft designs openly.  Put the rough first draft on the wiki/website/dev@ 
lis

Re: Why are large code drops damaging to a community?

[zeljko leskur]

Hi again ! Yes endeed ! As I have spoken I Am Always on dispositon gladly
could help if I would be able to do that. Of course without any obligation.
I could have oportunity learning from peoples who are highly, educated and
skillful on their Job. You can contact me whenever you want. Thank you very
much for paying your attention. Almost forgotten to Said important thing
that you are very pleasant,very smart and  by the way very cute and that is
a great combination.Thanks agan and we Will talking soon again. Wish you
very well.
Dana 18. 10. 2018. 14:25 osoba "Shane Curcuru" 
napisala je:

> Myrle Krantz wrote on 10/18/18 7:18 AM:
> > Hey all,
> >
> > There are many forms of offlist development.  One form of offlist
> > development is working on large code drops in private and then
> > contributing them all at once.  Threshold size is probably arguable,
> > and varies by project; put that aside for the moment.  I've been
> > working on an explanation of how large code drops damage community and
> > code.  I'd love to hear your feedback.  I'm including my project and
> > the dev@community list in the hopes that people from other projects
> > also have a perspective.  Here it goes:
>
> Thanks Myrle for an excellent writeup, including details of how large
> code drops harm Apache style open communities.  This is a great set of
> examples showing the "why" behind the ASF's requirement that the whole
> community be allowed to participate in *all* parts of a project's
> technical development.
>
> The requirement for an open and consensus-driven development process at
> the ASF doesn't just impact the individual perspective - which you've
> covered in detail in your post.  More importantly, it impacts the whole
> *community* ownership feeling of an Apache project.
>
> This is a key difference I see between Apache projects and
> maintainer-led projects.  There are many examples of maintainer projects
> with issues, successes, whatever.  But they primarily focus on how a
> handful of maintainers are struggling to keep their project growing for
> the benefit of all their users.
>
> The issue is the mindset of "maintainers".  An Apache project should
> have the entire community of contributors feeling like they have a stake
> in the project, that they can help build new ideas, and that they
> *share* as a whole group the direction of the project.  While much of
> the actions are the same, my point is about the feeling of ownership.
> It's not just a few "maintainers" driving things; it's *everyone* who's
> a committer (and hopefully soon, many of the contributors who get voted
> in).
>
> Offlist development prevents this truly shared sense of ownership from
> developing, which is why it's prohibited for Apache projects.
>
> ...snip...
> > Open source projects require transparency, not just as a moral value,
> > but as a pragmatic prerequisite for collaboration.  Offlist
> > development damages the community *and* the code.
>
> More to the point, repeated significant offlist development will attract
> the attention of the ASF board, which may well take direct action to
> prevent that kind of behavior from happening going forward.  One
> advantage of the ASF's independent governance is that it can enforce the
> core open development model that's a key part of the Apache Way.
>
> Note that I'm struggling to find where "offlist development is
> forbidden" is explicitly called out on the apache.org website, so
> pointers to existing places that *explain* this core concept and why
> it's important are appreciated.
>
> My attempt to explain how open development works is here:
>
>   http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24
>
> - Telegraph your intent: email dev@ with your *ideas* ahead of time.
> This allows feedback, encouragement, someone else to point out similar
> code is already over there, etc.
>
> - Draft designs openly.  Put the rough first draft on the
> wiki/website/dev@ list, and then do your edits *in public*.  This allows
> feedback on the architecture as it's being built, and again, gets better
> ideas.  It also allows a sense of community ownership.
>
> - Submit work in chunks (add: on a regular and frequent basis).  Checkin
> the shell of the API.  Then checkin each section of implementation.  If
> you're waiting for your code to look perfect before showing anyone else,
> you're not really helping the community.  Doing the development in the
> open allows for... you guessed it, feedback.
>
> - Welcome feedback along the way.  This doesn't mean you need to accept
> every change request or suggestion.  But it does mean you can take the
> best ideas from the whole community to add them easily, as the
> individual bits of work are being done.
>
> --
>
> - Shane
>   ComDev PMC
>   The Apache Software Foundation
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h.

Re: Why are large code drops damaging to a community?

[Shane Curcuru]

Myrle Krantz wrote on 10/18/18 7:18 AM:
> Hey all,
> 
> There are many forms of offlist development.  One form of offlist
> development is working on large code drops in private and then
> contributing them all at once.  Threshold size is probably arguable,
> and varies by project; put that aside for the moment.  I've been
> working on an explanation of how large code drops damage community and
> code.  I'd love to hear your feedback.  I'm including my project and
> the dev@community list in the hopes that people from other projects
> also have a perspective.  Here it goes:

Thanks Myrle for an excellent writeup, including details of how large
code drops harm Apache style open communities.  This is a great set of
examples showing the "why" behind the ASF's requirement that the whole
community be allowed to participate in *all* parts of a project's
technical development.

The requirement for an open and consensus-driven development process at
the ASF doesn't just impact the individual perspective - which you've
covered in detail in your post.  More importantly, it impacts the whole
*community* ownership feeling of an Apache project.

This is a key difference I see between Apache projects and
maintainer-led projects.  There are many examples of maintainer projects
with issues, successes, whatever.  But they primarily focus on how a
handful of maintainers are struggling to keep their project growing for
the benefit of all their users.

The issue is the mindset of "maintainers".  An Apache project should
have the entire community of contributors feeling like they have a stake
in the project, that they can help build new ideas, and that they
*share* as a whole group the direction of the project.  While much of
the actions are the same, my point is about the feeling of ownership.
It's not just a few "maintainers" driving things; it's *everyone* who's
a committer (and hopefully soon, many of the contributors who get voted in).

Offlist development prevents this truly shared sense of ownership from
developing, which is why it's prohibited for Apache projects.

...snip...
> Open source projects require transparency, not just as a moral value,
> but as a pragmatic prerequisite for collaboration.  Offlist
> development damages the community *and* the code.

More to the point, repeated significant offlist development will attract
the attention of the ASF board, which may well take direct action to
prevent that kind of behavior from happening going forward.  One
advantage of the ASF's independent governance is that it can enforce the
core open development model that's a key part of the Apache Way.

Note that I'm struggling to find where "offlist development is
forbidden" is explicitly called out on the apache.org website, so
pointers to existing places that *explain* this core concept and why
it's important are appreciated.

My attempt to explain how open development works is here:

  http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24

- Telegraph your intent: email dev@ with your *ideas* ahead of time.
This allows feedback, encouragement, someone else to point out similar
code is already over there, etc.

- Draft designs openly.  Put the rough first draft on the
wiki/website/dev@ list, and then do your edits *in public*.  This allows
feedback on the architecture as it's being built, and again, gets better
ideas.  It also allows a sense of community ownership.

- Submit work in chunks (add: on a regular and frequent basis).  Checkin
the shell of the API.  Then checkin each section of implementation.  If
you're waiting for your code to look perfect before showing anyone else,
you're not really helping the community.  Doing the development in the
open allows for... you guessed it, feedback.

- Welcome feedback along the way.  This doesn't mean you need to accept
every change request or suggestion.  But it does mean you can take the
best ideas from the whole community to add them easily, as the
individual bits of work are being done.

-- 

- Shane
  ComDev PMC
  The Apache Software Foundation

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Why are large code drops damaging to a community?

[zeljko leskur]

Something about this topic Firstly cause of practical reasons. As I have
noticed I Am opened to every colaboration and I would Like to give hand if
I could help withouth any obligations. Just friendly and freely. I do
appreciate you and your working. Sincerely yours.--Zeljko Leskur.
Dana 18. 10. 2018. 13:18 osoba "Myrle Krantz"  napisala
je:

> Hey all,
>
> There are many forms of offlist development.  One form of offlist
> development is working on large code drops in private and then
> contributing them all at once.  Threshold size is probably arguable,
> and varies by project; put that aside for the moment.  I've been
> working on an explanation of how large code drops damage community and
> code.  I'd love to hear your feedback.  I'm including my project and
> the dev@community list in the hopes that people from other projects
> also have a perspective.  Here it goes:
>
>
> Imagine you are an individual contributor on a project.  You would
> like to contribute something.  You see a feature you'd like to add or
> a bug you'd like to fix, a user you would like to support, or a
> release you'd like to test.  You start on it.  You submit your pull
> request, you answer the user's question, you test the release.  You
> continue doing this at a low level for a few months.  You see other
> people starting to contribute too.  This is nice.  You're working
> together with others towards a common goal.  Then, out of the blue a
> company with multiple paid contributors shows up.  Let's name them
> Acme. Acme drops a year of code on the project.  They could do this
> many ways.  For example:  A.) Acme could develop in the repository you
> were working in, or B.) Acme could create a project-internal fork and
> create a new repository. C.) Acme could even telegraph months in
> advance that they intend to do this, by posting to the dev list or
> contacting key contributors offlist, or just by having done it a few
> times already.
>
>
> A.) First let's imagine that Acme made massive changes in the
> repository you were working in.  Perhaps they already solved the
> problem you solved, but in a different way.  Perhaps, they deleted
> functions you made changes in.  Perhaps they added significant
> functionality you would have liked to help with.  What good were your
> efforts?  Wouldn't you find this discouraging?
>
> And now you want to continue to make changes, but the code you want to
> change has commit messages referencing tickets which you have no
> access to.  Or it has no reference to tickets at all.  You find an
> area that seems to be needlessly complex: can you remove the
> complexity?  You have no way of knowing what you'd be breaking.
>
> Perhaps you have a proprietary UI which depends on a behavior which
> was removed or changed.  Now your UI is broken.  Because the code drop
> is so large, you have no way to reasonably review it for
> incompatibilities.  It is not possible to review a year of development
> all at once.  And if your review turns up problems?  Do you accept the
> entire pull request or decline the whole thing?  Putting all the code
> into one pull request is a form of blackmail (commonly used in the
> formulation of bills for Congress).  If you want the good you have to
> take the bad.
>
>
> B.) Now let's imagine that Acme forked the code and created a new
> repository which they then added to the project.  None of the work you
> did is in this new repository.  If those features you implemented were
> important to you, you will have to re-introduce them into the new
> repository.
>
> You'll have to start from zero learning to work in the new repository.
> You also had no say in how that code was developed, so maybe the
> feature that you need is unnecessarily difficult to implement in that
> repository.   You don't know why things are the way they are there, so
> you're walking through a mine field without a map when you're making
> changes.
>
> And anyways, why is Acme Corp so certain you had nothing of value to add?
>
> Releasing this code also becomes contentious. Which of the two
> competing repositories gets released?  Both of them? How does the
> project communicate to users about how these pieces fit together.
>
>
> C.) Imagine Acme gave you lots of forewarning that this was coming.
> You still have no say in how the code is developed.  You know that
> anything you might contribute could be obsoleted.  You can't tell
> users whether the up-and-coming release will be compatible.  And
> what's the point in testing that release?  You don't know how to check
> that your needs are being considered in the architecture of the new
> code base.
>
> You have no sense of ownership over what comes out of that process.
>
> You see that nobody else outside of Acme is working on the project
> either, for the same reasons.
>
>
> Most contributors would get discouraged and prefer not to participate
> if those were the conditions.  If contributors didn't get discouraged,
> they would fairly quickly b

Re: Why are large code drops damaging to a community?

[zeljko leskur]

Hi ! Thank you very much for your mail and friendly and very I might Said
expert explanation . I do know that you're doing your Job but anyway I Am
highly respecting you and your knowledge. So I'll try to explain my
position and  at the same time descrobe my position. I will do that
honestly and real statement. So, I do love on Croatia or Hrvatska. My
formal education is economy high school . IT is likely half of university.
I'm fifty five now and I Am a retired Sergeant of Croatoan army . IT was
war Here but IT doesn't relating about our convetsation. I was started with
computers and net before ten years. I am working at laptops strictly and
this one is third since 2009.yrs. I was passed through all Windows
configurations and just before two months started with Linux. I did not
looked myself likely informatic knowledgeable person.I am just user who
knows
Dana 18. 10. 2018. 13:18 osoba "Myrle Krantz"  napisala
je:

> Hey all,
>
> There are many forms of offlist development.  One form of offlist
> development is working on large code drops in private and then
> contributing them all at once.  Threshold size is probably arguable,
> and varies by project; put that aside for the moment.  I've been
> working on an explanation of how large code drops damage community and
> code.  I'd love to hear your feedback.  I'm including my project and
> the dev@community list in the hopes that people from other projects
> also have a perspective.  Here it goes:
>
>
> Imagine you are an individual contributor on a project.  You would
> like to contribute something.  You see a feature you'd like to add or
> a bug you'd like to fix, a user you would like to support, or a
> release you'd like to test.  You start on it.  You submit your pull
> request, you answer the user's question, you test the release.  You
> continue doing this at a low level for a few months.  You see other
> people starting to contribute too.  This is nice.  You're working
> together with others towards a common goal.  Then, out of the blue a
> company with multiple paid contributors shows up.  Let's name them
> Acme. Acme drops a year of code on the project.  They could do this
> many ways.  For example:  A.) Acme could develop in the repository you
> were working in, or B.) Acme could create a project-internal fork and
> create a new repository. C.) Acme could even telegraph months in
> advance that they intend to do this, by posting to the dev list or
> contacting key contributors offlist, or just by having done it a few
> times already.
>
>
> A.) First let's imagine that Acme made massive changes in the
> repository you were working in.  Perhaps they already solved the
> problem you solved, but in a different way.  Perhaps, they deleted
> functions you made changes in.  Perhaps they added significant
> functionality you would have liked to help with.  What good were your
> efforts?  Wouldn't you find this discouraging?
>
> And now you want to continue to make changes, but the code you want to
> change has commit messages referencing tickets which you have no
> access to.  Or it has no reference to tickets at all.  You find an
> area that seems to be needlessly complex: can you remove the
> complexity?  You have no way of knowing what you'd be breaking.
>
> Perhaps you have a proprietary UI which depends on a behavior which
> was removed or changed.  Now your UI is broken.  Because the code drop
> is so large, you have no way to reasonably review it for
> incompatibilities.  It is not possible to review a year of development
> all at once.  And if your review turns up problems?  Do you accept the
> entire pull request or decline the whole thing?  Putting all the code
> into one pull request is a form of blackmail (commonly used in the
> formulation of bills for Congress).  If you want the good you have to
> take the bad.
>
>
> B.) Now let's imagine that Acme forked the code and created a new
> repository which they then added to the project.  None of the work you
> did is in this new repository.  If those features you implemented were
> important to you, you will have to re-introduce them into the new
> repository.
>
> You'll have to start from zero learning to work in the new repository.
> You also had no say in how that code was developed, so maybe the
> feature that you need is unnecessarily difficult to implement in that
> repository.   You don't know why things are the way they are there, so
> you're walking through a mine field without a map when you're making
> changes.
>
> And anyways, why is Acme Corp so certain you had nothing of value to add?
>
> Releasing this code also becomes contentious. Which of the two
> competing repositories gets released?  Both of them? How does the
> project communicate to users about how these pieces fit together.
>
>
> C.) Imagine Acme gave you lots of forewarning that this was coming.
> You still have no say in how the code is developed.  You know that
> anything you might contribute could be obsoleted.  You can

Re: FOSDEM 2019 BoF

[Zoran Regvart]

Hi Isabel,
thank you for responding. By "BoF" I mean birds of a feather[1]
session. I believe there were in the past, and I presume there still
are planned for FOSDEM 2019. These are informal sessions for people
with common interest to get together and meet to discuss or work
together.

I (now) see that there is a conference planning software[2] using
which I can just submit an event, I'm unsure if this is the way to
ask/reserve for the venue and I can't find any explanation on how one
does this.

zoran

[1] https://en.wikipedia.org/wiki/Birds_of_a_feather_(computing)
[2] https://penta.fosdem.org/submission/FOSDEM19/

On Thu, Oct 18, 2018 at 1:26 PM, Isabel Drost-Fromm  wrote:
> Hi Zoran,
>
> On 18/10/2018 12:39, Zoran Regvart wrote:
>>
>> in the Camel project we're discussing a BoF session at the FOSDEM
>> 2019. I've tried to reach out via the FOSDEM mailing list but got no
>> reply. I know that other ASF project have had BoF sessions at FOSDEM
>> can anyone point me to the right way of organizing one?
>
>
> What exactly do you mean when referring to BOF sessions at FOSDEM?
>
> To my knowledge FOSDEM does have
>
> - talks in main tracks, CfP still open, reviews done by the main org team
> - dev rooms, those are one or two day community organised tracks on specific
> topics, call for dev room topics IIRC has closed, dev rooms have been
> announced and are open for talk submissions.
> - people meeting independently for dinner during the conference at
> restaurants nearby, often focussed on specific topics
> - some events co-located but organised independently at the same weekend (or
> week before/after) at locations nearby like meetups and the like.
>
> Hope the above helps you a bit,
> Isabel
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>



-- 
Zoran Regvart

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: FOSDEM 2019 BoF

[Isabel Drost-Fromm]

Hi Zoran,

On 18/10/2018 12:39, Zoran Regvart wrote:

in the Camel project we're discussing a BoF session at the FOSDEM
2019. I've tried to reach out via the FOSDEM mailing list but got no
reply. I know that other ASF project have had BoF sessions at FOSDEM
can anyone point me to the right way of organizing one?


What exactly do you mean when referring to BOF sessions at FOSDEM?

To my knowledge FOSDEM does have

- talks in main tracks, CfP still open, reviews done by the main org team
- dev rooms, those are one or two day community organised tracks on 
specific topics, call for dev room topics IIRC has closed, dev rooms 
have been announced and are open for talk submissions.
- people meeting independently for dinner during the conference at 
restaurants nearby, often focussed on specific topics
- some events co-located but organised independently at the same weekend 
(or week before/after) at locations nearby like meetups and the like.


Hope the above helps you a bit,
Isabel


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Why are large code drops damaging to a community?

[Myrle Krantz]

Hey all,

There are many forms of offlist development.  One form of offlist
development is working on large code drops in private and then
contributing them all at once.  Threshold size is probably arguable,
and varies by project; put that aside for the moment.  I've been
working on an explanation of how large code drops damage community and
code.  I'd love to hear your feedback.  I'm including my project and
the dev@community list in the hopes that people from other projects
also have a perspective.  Here it goes:


Imagine you are an individual contributor on a project.  You would
like to contribute something.  You see a feature you'd like to add or
a bug you'd like to fix, a user you would like to support, or a
release you'd like to test.  You start on it.  You submit your pull
request, you answer the user's question, you test the release.  You
continue doing this at a low level for a few months.  You see other
people starting to contribute too.  This is nice.  You're working
together with others towards a common goal.  Then, out of the blue a
company with multiple paid contributors shows up.  Let's name them
Acme. Acme drops a year of code on the project.  They could do this
many ways.  For example:  A.) Acme could develop in the repository you
were working in, or B.) Acme could create a project-internal fork and
create a new repository. C.) Acme could even telegraph months in
advance that they intend to do this, by posting to the dev list or
contacting key contributors offlist, or just by having done it a few
times already.


A.) First let's imagine that Acme made massive changes in the
repository you were working in.  Perhaps they already solved the
problem you solved, but in a different way.  Perhaps, they deleted
functions you made changes in.  Perhaps they added significant
functionality you would have liked to help with.  What good were your
efforts?  Wouldn't you find this discouraging?

And now you want to continue to make changes, but the code you want to
change has commit messages referencing tickets which you have no
access to.  Or it has no reference to tickets at all.  You find an
area that seems to be needlessly complex: can you remove the
complexity?  You have no way of knowing what you'd be breaking.

Perhaps you have a proprietary UI which depends on a behavior which
was removed or changed.  Now your UI is broken.  Because the code drop
is so large, you have no way to reasonably review it for
incompatibilities.  It is not possible to review a year of development
all at once.  And if your review turns up problems?  Do you accept the
entire pull request or decline the whole thing?  Putting all the code
into one pull request is a form of blackmail (commonly used in the
formulation of bills for Congress).  If you want the good you have to
take the bad.


B.) Now let's imagine that Acme forked the code and created a new
repository which they then added to the project.  None of the work you
did is in this new repository.  If those features you implemented were
important to you, you will have to re-introduce them into the new
repository.

You'll have to start from zero learning to work in the new repository.
You also had no say in how that code was developed, so maybe the
feature that you need is unnecessarily difficult to implement in that
repository.   You don't know why things are the way they are there, so
you're walking through a mine field without a map when you're making
changes.

And anyways, why is Acme Corp so certain you had nothing of value to add?

Releasing this code also becomes contentious. Which of the two
competing repositories gets released?  Both of them? How does the
project communicate to users about how these pieces fit together.


C.) Imagine Acme gave you lots of forewarning that this was coming.
You still have no say in how the code is developed.  You know that
anything you might contribute could be obsoleted.  You can't tell
users whether the up-and-coming release will be compatible.  And
what's the point in testing that release?  You don't know how to check
that your needs are being considered in the architecture of the new
code base.

You have no sense of ownership over what comes out of that process.

You see that nobody else outside of Acme is working on the project
either, for the same reasons.


Most contributors would get discouraged and prefer not to participate
if those were the conditions.  If contributors didn't get discouraged,
they would fairly quickly be taking orders from the employees of Acme
Corp.  Acme Corp has all the inside information about what's coming in
a year in the next code dump.  Information is power.  Contributors who
are also users may also chose to stop contributing and become free
riders.  Why not just depend on Acme Corp for all of the development?

What Acme seems to be getting out of this scenario is an Apache
feather.  It's a form of free-riding on Apache's reputation.


Now let's imagine that you are the CTO of another company, 

FOSDEM 2019 BoF

[Zoran Regvart]

Hi,
in the Camel project we're discussing a BoF session at the FOSDEM
2019. I've tried to reach out via the FOSDEM mailing list but got no
reply. I know that other ASF project have had BoF sessions at FOSDEM
can anyone point me to the right way of organizing one?

thanks :)

zoran
-- 
Zoran Regvart

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [Mifos-users] Dev vs User Mailing Lists

[jubha mayala]

Many users do enjoy the mail lists by browsing answered queries and solved
problems, which in Whatsapp or real time chat is quiet difficult to trace
these kind of things!

Regards,
Jimmy

On Thu, Oct 18, 2018 at 7:08 AM Santosh Math <
sant...@confluxtechnologies.com> wrote:

> +1
>
> On Thu, Oct 18, 2018 at 12:53 AM Joan Touzet  wrote:
>
>> Thanks for the info, Bertrand.
>>
>> Mailing lists can be just as exclusive as semi-synchronous environments.
>> They may not work for your community, but they work for ours, and removing
>> them will necessarily disadvantage many contributors.
>>
>> I'm firmly of the opinion that you can't completely ignore real-time
>> communications and expect 100% of everything to occur asynchronously on
>> mailing lists. It explicitly disallows certain types of communication that
>> you can't have in a mailing list. You have the imposition of the formality
>> of a mailing list for newcomers, you have the "being on record" syndrome,
>> you have the "must be subscribed to post" problem (not always), and finally
>> you are ignoring the fact that people will talk real time anyway - so why
>> not make that a venue that you at least have some control/visibility over?
>> In fact, my doctoral research was on how semi-synchronous communications
>> support distance work and learning better than fully asynchronous ones
>>
>> -Joan
>>
>> - Original Message -
>> From: "Bertrand Delacretaz" 
>> To: "dev" 
>> Cc: d...@fineract.apache.org, "Myrle Krantz" ,
>> mifos-develo...@lists.sourceforge.net, mifos-us...@lists.sourceforge.net,
>> u...@fineract.apache.org
>> Sent: Wednesday, October 17, 2018 12:04:27 PM
>> Subject: Re: Dev vs User Mailing Lists
>>
>> On Tue, Oct 16, 2018 at 7:46 PM  wrote:
>> >
>> > ...[ASIDE] Realtime communications are not inclusive...
>>
>> FWIW there was a good discussion about this recently in Apache Arrow:
>>
>>
>> https://lists.apache.org/thread.html/8433cda04dc9e1d6bb235e4f29bde30d07c3e5d81177af785af177f2@%3Cdev.arrow.apache.org%3E
>>
>> -Bertrand
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>>
>
>
> --
> Thanks & Regards
>
> Santosh Math
>
> *QA Engineer*
>
> *Conflux Technologies Pvt Ltd *
> | *Office*: +91-080-41208662 |
>
> *Address*: #304, 2nd Floor, 7th Main Road, HRBR Layout 1st Block,
> Bengaluru, Karnataka, 560043 INDIA
> ___
> Mifos-users mailing list
> mifos-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mifos-users
>

Re: Dev vs User Mailing Lists

[Bertrand Delacretaz]

Hi Joan,

On Wed, Oct 17, 2018 at 9:18 PM Joan Touzet  wrote:
> ...I'm firmly of the opinion that you can't completely ignore real-time
> communications and expect 100% of everything to occur asynchronously
> on mailing lists

I totally agree with that, as you say synchronous discussions will
happen anyway and that's good.

OTOH I think we have a number of podlings, and maybe projects, for
which the dev list seems to be just an annoyance, things happen on
Slack anyway so who cares? I'm pushing it a bit here but just a bit.

I think there's a balance to be found, and in that sense it's great if
people can tell the stories of what works in their projects. Blog
posts in the "Success at Apache" series or under
https://blogs.apache.org/comdev/ would be *very* welcome, and I'm
happy to help make them happen, review etc. if desired.

Is your doctoral research available online? It sounds quite relevant
to what we're discussing here.

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org