That's an interesting experiment. From new contributor's aspect, I would see more small feature project ideas (just like rust community do). Since existing beginner issues give new contributors a vague roadmap what they should do next.
On Thu, Jun 29, 2017 at 1:53 PM, Sourabh Bajaj < [email protected]> wrote: > The Rust community is trying an interesting experiment for encouraging more > diversity in the contributors: > https://blog.rust-lang.org/2017/06/27/Increasing-Rusts-Reach.html > > On Fri, Apr 28, 2017 at 12:05 PM Sourabh Bajaj <[email protected]> > wrote: > > > I think they can probably reach out to the mentor for questions like: How > > to navigate the code base? What parts of the code could they use as a > > pattern? This could be done using the preferred mode of communication > based > > on the contributor. > > > > My opinion is that large projects and communities may come across as > > intimidating to first time contributors, so being as welcoming and > > encouraging is important. > > > > On Thu, Apr 27, 2017 at 8:52 PM Aviem Zur <[email protected]> wrote: > > > >> @ > >> Sourabh Bajaj > >> > >> The mentoring on starter tickets is an interesting Idea. How would it > >> technically work?. > >> > >> A new contributor assigns a starter ticket to themselves. What happens > >> from > >> there? > >> > >> On Tue, Apr 25, 2017 at 12:01 PM Ismaël Mejía <[email protected]> > wrote: > >> > >> > I think it is important to clarify that the developer documentation > >> > discussed in this thread is of two kinds: > >> > > >> > 6.1. Documents with proposals and new designs, those covered by the > >> > Beam Improvement Proposal (BEAM-566), and that we need to put with a > >> > single file index (I remember there was a google dir for this but not > >> > sure it is still valid, and in any case probably the website is a > >> > better place for this). Is there any progress on this? > >> > > >> > 6.2. Documentation about how things work, so new developers can get > >> > into developing features/fixes for the project, those are the kind > >> > that Kenneth/Etienne mention and include Stephen’s IO guide but could > >> > be definitely expanded to include things like how does the different > >> > runner translation works, or some details on triggers/materialization > >> > of panes/windows from the SDK point of view. However the hard part of > >> > this documents is that they should be maintained e.g. updated when the > >> > code evolves so they don’t get outdated as JB mentions. > >> > > >> > On Tue, Apr 25, 2017 at 10:47 AM, Wesley Tanaka > >> > <[email protected]> wrote: > >> > > These are the ones I've come across so far, are there others? > >> > > > >> > > * Dynamic DoFn https://s.apache.org/a-new-dofn > >> > > > >> > > ** Splittable DoFn (Obsoletes Source API) > >> > http://s.apache.org/splittable-do-fn > >> > > > >> > > ** State and Timers for DoFn: https://s.apache.org/beam-state > >> > > > >> > > > >> > > * Lateness https://s.apache.org/beam-lateness > >> > > > >> > > > >> > > * Metrics API http://s.apache.org/beam-metrics-api > >> > > > >> > > ** I/O Metrics https://s.apache.org/standard-io-metrics > >> > > > >> > > > >> > > * Runner API http://s.apache.org/beam-runner-api > >> > > > >> > > ** https://s.apache.org/beam-runner-composites > >> > > > >> > > ** https://s.apache.org/beam-side-inputs-1-pager > >> > > > >> > > > >> > > * Fn API http://s.apache.org/beam-fn-api > >> > > > >> > > --- > >> > > Wesley Tanaka > >> > > https://wtanaka.com/ > >> > > > >> > > > >> > > On Monday, April 24, 2017, 2:45:45 PM HST, Sourabh Bajaj < > >> > [email protected]> wrote: > >> > > For 6. I think having them in one page on the website where we can > >> find > >> > the > >> > > design docs more easily would be great. > >> > > > >> > > 7. For low-hanging-fruit, one thing I really liked from some Mozilla > >> > > projects was assigning a mentor on the ticket. Someone you can reach > >> out > >> > to > >> > > if you have questions. I think this makes the entry barrier really > low > >> > for > >> > > first time contributors who might feel intimidated asking questions > >> > > completely in public. > >> > > > >> > > On Mon, Apr 24, 2017 at 10:06 AM Kenneth Knowles > >> <[email protected] > >> > > > >> > > wrote: > >> > > > >> > >> I like the subject Etienne has brought up, and will give it a > number > >> in > >> > >> this list :-) > >> > >> > >> > >> 6. Have more technical reference docs (not just workspace set up) > for > >> > >> contributors. > >> > >> > >> > >> I think this overlaps a lot with a prior discussion about where to > >> > collect > >> > >> design proposals [1]. Design docs used to be just dropped into a > >> public > >> > >> folder, but that got disorganized. And that thread was about work > in > >> > >> progress, so JIRA was a good place for details after a dev@ thread > >> > agrees > >> > >> on a proposal. At this point, the designs are pretty solid > >> conceptually > >> > or > >> > >> even implemented and we could start to build out deeper technical > >> bits > >> > on > >> > >> the web site, or at least some place that people can find it. We do > >> have > >> > >> the Testing Guide and the PTransform Style Guide and somewhere near > >> > there > >> > >> we could have deeper references. I think we need a broader vision > for > >> > the > >> > >> "table of contents" here. > >> > >> > >> > >> For my docs (triggers, lateness, runner API, side inputs, state, > >> > coders) I > >> > >> haven't had time, but I do intend to both translate from GDoc to > some > >> > other > >> > >> format and also rewrite versions for users where appropriate. > >> Probably > >> > this > >> > >> will mean coming up with that table of contents. > >> > >> > >> > >> Kenn > >> > >> > >> > >> [1] > >> > >> > >> > >> > >> > > >> https://lists.apache.org/thread.html/%3C6bc60c88-cf91- > [email protected]%3E > >> > >> > >> > >> > >> > >> On Mon, Apr 24, 2017 at 9:33 AM, Neelesh Salian < > >> > [email protected]> > >> > >> wrote: > >> > >> > >> > >> > Agreed. I have some old JIRAs that I am cleaning up. > >> > >> > > >> > >> > Thank you for bringing this up. > >> > >> > > >> > >> > On Mon, Apr 24, 2017 at 9:29 AM, Jean-Baptiste Onofré < > >> > [email protected]> > >> > >> > wrote: > >> > >> > > >> > >> > > Same also for Slack, github comments, etc. > >> > >> > > > >> > >> > > From a Apache perspective, it should happen on the mailing > list, > >> > >> > > eventually referencing a central wiki/faq/whatever. > >> > >> > > > >> > >> > > Regards > >> > >> > > JB > >> > >> > > > >> > >> > > > >> > >> > > On 04/24/2017 06:23 PM, Mingmin Xu wrote: > >> > >> > > > >> > >> > >> many design documents are mixed in maillist, jira comments, it > >> > would > >> > >> be > >> > >> > a > >> > >> > >> big help to put them in a centralized list. Also I would > expect > >> > more > >> > >> > >> wiki/blogs to provide in-depth analysis, like the translation > >> from > >> > >> > >> pipeline > >> > >> > >> to runner specified topology, window/trigger implementation. > >> > Without > >> > >> > these > >> > >> > >> knowledge, it's hard to touch the core concepts. > >> > >> > >> > >> > >> > >> On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofré < > >> > >> [email protected]> > >> > >> > >> wrote: > >> > >> > >> > >> > >> > >> Got it. By experience on other Apache projects, it's really > >> hard to > >> > >> > >>> maintain ;) > >> > >> > >>> > >> > >> > >>> Regards > >> > >> > >>> JB > >> > >> > >>> > >> > >> > >>> > >> > >> > >>> On 04/24/2017 02:56 PM, Etienne Chauchot wrote: > >> > >> > >>> > >> > >> > >>> Hi JB, > >> > >> > >>>> > >> > >> > >>>> I was proposing a FAQ (or another form), not something about > >> IDE > >> > >> > setup. > >> > >> > >>>> The FAQ > >> > >> > >>>> could group in the same place Q/A like for example "what is > a > >> > >> source, > >> > >> > >>>> how > >> > >> > >>>> do I > >> > >> > >>>> use it to implement an IO" > >> > >> > >>>> > >> > >> > >>>> Etienne > >> > >> > >>>> > >> > >> > >>>> > >> > >> > >>>> Le 24/04/2017 à 14:19, Jean-Baptiste Onofré a écrit : > >> > >> > >>>> > >> > >> > >>>> Hi Etienne, > >> > >> > >>>>> > >> > >> > >>>>> What about the contribution guide ? I think it's covered in > >> the > >> > >> > >>>>> IntelliJ > >> > >> > >>>>> and > >> > >> > >>>>> Eclipse setup sections. > >> > >> > >>>>> > >> > >> > >>>>> Regards > >> > >> > >>>>> JB > >> > >> > >>>>> > >> > >> > >>>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote: > >> > >> > >>>>> > >> > >> > >>>>> Hi all, > >> > >> > >>>>>> > >> > >> > >>>>>> I definitely agree with everything that is said in this > >> thread. > >> > >> > >>>>>> > >> > >> > >>>>>> I might suggest another good to have: > >> > >> > >>>>>> > >> > >> > >>>>>> to ease the work of a new contributor, it would be nice to > >> have > >> > >> some > >> > >> > >>>>>> sort of > >> > >> > >>>>>> programming guide but not oriented to pipeline writers but > >> to > >> > >> > >>>>>> sdk/runner/io/... > >> > >> > >>>>>> writers. > >> > >> > >>>>>> > >> > >> > >>>>>> I know that new contributors have the docs available in > the > >> > google > >> > >> > >>>>>> drive, the > >> > >> > >>>>>> ML, the code base, and the availability of beamers, but > >> maybe > >> > >> having > >> > >> > >>>>>> key points > >> > >> > >>>>>> in a common place (like FAQ for sdk/runner/io/... writers, > >> for > >> > >> > >>>>>> example) > >> > >> > >>>>>> would be > >> > >> > >>>>>> interesting. > >> > >> > >>>>>> > >> > >> > >>>>>> Best, > >> > >> > >>>>>> > >> > >> > >>>>>> Etienne > >> > >> > >>>>>> > >> > >> > >>>>>> > >> > >> > >>>>>> Le 24/04/2017 à 09:14, Jean-Baptiste Onofré a écrit : > >> > >> > >>>>>> > >> > >> > >>>>>> Hi, > >> > >> > >>>>>>> > >> > >> > >>>>>>> I think we already tag the newbie jira ("low hanging > fruit" > >> > ;)). > >> > >> > >>>>>>> > >> > >> > >>>>>>> Good idea for domain of interest/concept. > >> > >> > >>>>>>> > >> > >> > >>>>>>> Regards > >> > >> > >>>>>>> JB > >> > >> > >>>>>>> > >> > >> > >>>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote: > >> > >> > >>>>>>> > >> > >> > >>>>>>> Might I suggest adding tags to projects based on area of > >> > >> intetest, > >> > >> > >>>>>>>> concept > >> > >> > >>>>>>>> and if it's a good "first bug". > >> > >> > >>>>>>>> > >> > >> > >>>>>>>> Sent from my iPhone > >> > >> > >>>>>>>> > >> > >> > >>>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci < > [email protected] > >> > > >> > >> wrote: > >> > >> > >>>>>>>> > >> > >> > >>>>>>>> > >> > >> > >>>>>>>> 1. Have people unassign themselves from issues they're > not > >> > >> > actively > >> > >> > >>>>>>>>>> working on. > >> > >> > >>>>>>>>>> 2. Have the community engage more in triage, improving > >> > tickets > >> > >> > >>>>>>>>>> descriptions and raising concerns. > >> > >> > >>>>>>>>>> 3. Clean house - apply (2) to currently open issues > >> (over > >> > >> 800). > >> > >> > >>>>>>>>>> Perhaps > >> > >> > >>>>>>>>>> some can be closed. > >> > >> > >>>>>>>>>> > >> > >> > >>>>>>>>>> > >> > >> > >>>>>>>>>> +1 on all three of these, and will do my part shortly! > >> > >> > >>>>>>>>> > >> > >> > >>>>>>>>> Also, it is worth noting that we have improved as a > >> project > >> > in > >> > >> > >>>>>>>>> tracking > >> > >> > >>>>>>>>> issues in the last 1-2 months. There are more resolved > >> > issues > >> > >> > than > >> > >> > >>>>>>>>> opened > >> > >> > >>>>>>>>> in this period, whereas in the past we'd have a hundred > >> more > >> > >> > opened > >> > >> > >>>>>>>>> than > >> > >> > >>>>>>>>> resolved. > >> > >> > >>>>>>>>> > >> > >> > >>>>>>>>> I would also propose to not assign new Jira > >> automatically: > >> > now, > >> > >> > the > >> > >> > >>>>>>>>> Jira is > >> > >> > >>>>>>>>> > >> > >> > >>>>>>>>> automatically assigned to the Jira component leader. > >> > >> > >>>>>>>>>> > >> > >> > >>>>>>>>>> > >> > >> > >>>>>>>>>> Imagine a user discovering an issue and filing a new > >> JIRA > >> > >> issue. > >> > >> > >>>>>>>>> It > >> > >> > >>>>>>>>> wouldn't be assigned to anyone, significantly reducing > >> the > >> > >> chance > >> > >> > >>>>>>>>> somebody > >> > >> > >>>>>>>>> will actually help. > >> > >> > >>>>>>>>> > >> > >> > >>>>>>>>> Of course, somebody could search for new issues > >> > periodically, > >> > >> > etc. > >> > >> > >>>>>>>>> -- but > >> > >> > >>>>>>>>> that just won't happen. The final outcome would be -- > >> > instead > >> > >> of > >> > >> > a > >> > >> > >>>>>>>>> lot of > >> > >> > >>>>>>>>> issues assigned to component leads, we'd have (much) > more > >> > >> > >>>>>>>>> unassigned > >> > >> > >>>>>>>>> issues, which were *never* looked at. Assigning an > issue > >> > just > >> > >> > sets > >> > >> > >>>>>>>>> a > >> > >> > >>>>>>>>> community expectation that a committer should look -- > >> and it > >> > >> does > >> > >> > >>>>>>>>> help move > >> > >> > >>>>>>>>> things along! > >> > >> > >>>>>>>>> > >> > >> > >>>>>>>>> I think a better approach of addressing the current > state > >> > would > >> > >> > be > >> > >> > >>>>>>>>> increase > >> > >> > >>>>>>>>> the number of components / component leads. With more > >> people > >> > >> > >>>>>>>>> involved and > >> > >> > >>>>>>>>> lower per-person load, I think we'd be more effective. > >> > >> > >>>>>>>>> > >> > >> > >>>>>>>>> > >> > >> > >>>>>>>> > >> > >> > >>>>>>> > >> > >> > >>>>>> > >> > >> > >>>>> > >> > >> > >>>> -- > >> > >> > >>> Jean-Baptiste Onofré > >> > >> > >>> [email protected] > >> > >> > >>> http://blog.nanthrax.net > >> > >> > >>> Talend - http://www.talend.com > >> > >> > >>> > >> > >> > >>> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > -- > >> > >> > > Jean-Baptiste Onofré > >> > >> > > [email protected] > >> > >> > > http://blog.nanthrax.net > >> > >> > > Talend - http://www.talend.com > >> > >> > > > >> > >> > > >> > >> > > >> > >> > > >> > >> > -- > >> > >> > Regards, > >> > >> > Neelesh S. Salian > >> > >> > > >> > >> > >> > > >> > > >
