I would be willing to help triage and help prioritize bugs according to difficulty if needed so that any new contributors can have a bit more of an easy point of entry to the project.
Sent from my iPhone > On 17 Oct 2017, at 13:18, Andrew Williams <a...@andywilliams.me> wrote: > > Hi, > > There is a concerted effort now to try and fix up the documentation of EFL > for devs / contributors and for users of our apps. > The dev portion of this is obviously largely based around the interfaces > work as everything will be "legacy" at some point in the near future. > We only have a limited time available to get all this done and I think we > should be able to publish the docs at completion if not before. > Therefore it is becoming more important to figure out where we are going to > get to, by when (or at least a target that we can all agree on). > > Given that the parent ticket https://phab.enlightenment.org/T5301 was > created in March and we're in October now with around 1/3 - 1/2 of the work > done (guesstimating here as there is no obvious way to see how much > progress we are making (only about 1/5 of tickets are closed off)) and even > in the last month we are adding new sub-tasks twice as fast as we are > closing tickets it seems like an impractical target to get any sort of > stable interfaces API subset ready for the end of the year. > > I really think we need to get a handle on this - agree what *must* be done > to even have a "ready to start being used" API so we can focus and finally > get something out of the door to build on. > My proposal is this: A new parent ticket is created for "Nice to have > Interfaces" and another for "Not first release Interfaces" and we move > everything off that main ticket that is non-essential. Only then will we > get a feeling for what remains. > > Personally I find moving targets difficult to work to and very morale > draining - I'd be very surprised if there are not others out there feeling > the same way. > Thanks, and as always please fire your thoughts back team :). > Andrew > >> On Tue, 12 Sep 2017 at 12:44 Carsten Haitzler <ras...@rasterman.com> wrote: >> >> On Tue, 12 Sep 2017 09:50:18 +0000 Andrew Williams <a...@andywilliams.me> >> said: >> >>> Hi, >>> >>> This is good to hear. Reflecting on it I think what I missed was the >>> clarity that 1.21 would not be released until these interfaces are >> stable. >> >> Actually that's not set in stone. We may release a 1.21 and defer >> interfaces >> for 1.22. It depends on timing and where things get to by what time. The >> way we >> are doing things, interfaces is an OPTIONAL blocker for a release. It's >> not a >> technical one. The GOAL is to have 1.21 by end of year or so with >> interfaces >> "ready to begin to be used as a stable API". >> >>> Having been looking for this since 1.19 I'm thrilled but wonder if >> everyone >>> is on the same page (maybe it was only clear within Samsung crew?). >> Should >>> we be documenting somewhere like an upcoming releases page that, whilst >>> normally a timed cycle, for this release we have a specific goal in mind >>> rather than a date? >>> >>> Thanks, >>> Andy >>> On Mon, 21 Aug 2017 at 13:24, Carsten Haitzler <ras...@rasterman.com> >> wrote: >>> >>>> On Mon, 21 Aug 2017 12:08:46 +0000 Andrew Williams < >> a...@andywilliams.me> >>>> said: >>>> >>>>> Hi, >>>>> >>>>> In a word no. What that is is an ever growing list of work we would >> like >>>> to >>>>> get done. That's not really a planning tool it's a log. >>>>> Planning for what goes into a release is a different beast - we make >> a >>>> list >>>>> of what's required, agree on it and start working through. >>>> >>>> that actually is the list of things to go into 1.21 (efl interfaces >> "done" >>>> release)... :) >>>> >>>>> Surely in planning for a release you need either a) a delivery date >> and a >>>>> prioritised list or b) a requirements list and an agreed scope. >>>>> A list of things that gets added to as we work through is not either >> of >>>>> those - the list could grow forever and never get finished... >>>> >>>> things are discovered as the work is done. the goal is clear make >> eo/efl >>>> interfaces stable and ready to use for application devs". >>>> >>>>> Andy >>>>> On Mon, 21 Aug 2017 at 11:41, Carsten Haitzler <ras...@rasterman.com >>> >>>> wrote: >>>>> >>>>>> On Sat, 15 Jul 2017 20:12:34 +0000 Andrew Williams < >>>> a...@andywilliams.me> >>>>>> said: >>>>>> >>>>>> just saying... isn't >>>>>> >>>>>> https://phab.enlightenment.org/T5301 >>>>>> >>>>>> good enough? i mean it does what's needed. tacks a todo list and >> even >>>>>> dependencies... etc. >>>>>> >>>>>>> Hi team, >>>>>>> >>>>>>> As many would probably agree by now we have a very high ticket >> volume >>>>>> which >>>>>>> is rather hard to manage... Whilst folk are doing a great job of >>>>>>> marshalling the incoming tasks I think that some more structure >> would >>>>>> help >>>>>>> us to see what is needed in each area and for the next release >> etc... >>>>>>> >>>>>>> In preparation for 1.21 I would like to start working on this a >>>> little to >>>>>>> help us manage the work for our next release (especially as it >> will >>>> be >>>>>> the >>>>>>> eo interfaces release!) and propose to do the following in phab, >> as >>>> it is >>>>>>> otherwise managing to keep track well: >>>>>>> >>>>>>> * Add a milestone to efl phab project for the next release - this >>>> will be >>>>>>> used to mark the issues we have agreed must go into the next >> release >>>>>>> * Add sub projects for each area of EFL so we can better >> categorise >>>> the >>>>>>> tasks (we can either use EFL or a "common" subproject for those >> that >>>>>> apply >>>>>>> to all >>>>>>> * efl-eina >>>>>>> * efl-eolian >>>>>>> * efl-canvas >>>>>>> * efl-canvas-layout >>>>>>> * efl-ui >>>>>>> (etc etc) >>>>>>> >>>>>>> Notice the use of the new namespaces for everything in the >>>> interfaces - >>>>>>> this is surely how we should be thinking going forward :) >>>>>>> If we are able to split things out a bit more then we can have >> more >>>>>> people >>>>>>> assigned to projects with fewer issues per project. >>>>>>> Then the milestone for release can be the main point of concern >> for a >>>>>>> release manager :) >>>>>>> >>>>>>> I wanted to throw the concept out to the list before doing >> anything >>>> in >>>>>> case >>>>>>> there are any concerns with this approach that I may have missed? >>>>>>> >>>>>>> Thanks :) >>>>>>> Andy >>>>>>> -- >>>>>>> http://andywilliams.me >>>>>>> http://ajwillia.ms >>>>>>> >>>>>> >>>> >> ------------------------------------------------------------------------------ >>>>>>> Check out the vibrant tech community on one of the world's most >>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>>> _______________________________________________ >>>>>>> enlightenment-devel mailing list >>>>>>> enlightenment-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------- Codito, ergo sum - "I code, therefore I am" >>>> -------------- >>>>>> The Rasterman (Carsten Haitzler) ras...@rasterman.com >>>>>> >>>>>> -- >>>>> http://andywilliams.me >>>>> http://ajwillia.ms >>>> >>>> >>>> -- >>>> ------------- Codito, ergo sum - "I code, therefore I am" >> -------------- >>>> The Rasterman (Carsten Haitzler) ras...@rasterman.com >>>> >>>> -- >>> http://andywilliams.me >>> http://ajwillia.ms >> >> >> -- >> ------------- Codito, ergo sum - "I code, therefore I am" -------------- >> Carsten Haitzler - ras...@rasterman.com >> >> -- > http://andywilliams.me > http://ajwillia.ms > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
