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" <a...@shanecurcuru.org> 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...@community.apache.org > >
