I've responded inline below. On Monday, August 29, 2016 at 1:08:29 PM UTC-4, [email protected] wrote: > > > - fix issues that are in progress > > <https://github.com/LightTable/LightTable/issues?q=is%3Aopen+is%3Aissue+label%3A%22in+progress%22> > > (currently 3) > > This would be nice.
But honestly only finishing fixing the LT self-upgrading is really crucial. I don't think there's much point in publishing the next release before finishing this. Everyone would need to download the new release to upgrade. Maybe if there was a critical bug discovered (that was also easy to fix), we could publish another release before finishing the upgrading fix, but otherwise it's definitely going to be included in the next r One of the other open issues is a purely internal change. The third issue is for a very minor feature but it's waiting for approval from the rest of the core team. > > - fix one of the top 2 features requested by users > <https://www.bountysource.com/teams/lighttable/issues> (#662 > <https://github.com/LightTable/LightTable/issues/662> or #533 > <https://github.com/LightTable/LightTable/issues/533>) > > Both of those are pretty major features but none of the core team is interested in implementing them. Nor is anyone else apparently. If I had to guess, the shell-in-a-tab feature is probably (much) easier to implement. In fact, one can get most of the way just by using Butterfly <http://paradoxxxzero.github.io/2014/02/28/butterfly.html> and connect to it in a LT browser tab. I tried it a long while ago and there were some quirks, but it definitely 'worked'. Others have partially implemented LT plugins to wrap Butterfly but it doesn't seem like any have finished any. Wait – I was wrong. The plugin Terminal <https://github.com/alun/terminal> is exactly this. Given that, I just closed the issue. Anyone interested can contribute towards the further development of the plugin. > > - list all issues and PRs that were fixed since 0.8.1 (that can be > done automatically) in the changelog > > Gabriel has been adding to the CHANGELOG each release but automating at least part of doing that is probably a welcome idea. It's possible he's already been using, e.g. a GitHub search to do something similar. I'm not aware of anything being excluded from the CHANGELOG in previous releases so I'm not sure if this is criticizing past performance or simply suggesting better practice. > > - review the queued PRs that are in progress > > <https://github.com/LightTable/LightTable/pulls?q=is%3Aopen+is%3Apr+label%3A%22in+progress%22> > > (currently 5) > > Yes, let's do this. Unfortunately, the project convention has been for the core team to achieve rough consensus about significant changes before merging and all of us have been relatively inactive over the past several months. But we need to achieve consensus somehow, or change or replace our conventions for the project, so, somehow, this will be solved and we'll do something with the in-progress PRs. > > - move some issues from 0.9 to a new 0.8.3 milestone > - add a candidate-next* label for futur milestones > > Right now our bottleneck is time – people spending time writing *and reading *code, QA-ing changes, and doing all of the 'admin' maintenance like replying to threads in this group, following-up with people in GitHub for issues they open, etc. I'm, personally, not even comfortable adding *anything *to milestones, except maybe one or two critical issues at a time. The reason being that I don't want to commit myself or, more importantly, other contributors, to delivering something. It's important to manage expectations and right now those expectations should be *minimal*, as all of the contributors are very much part-time (and unpaid). I'm not against multiple milestones, but I'm against my committing to any right now. If any other contributors want to commit themselves to delivering features or fixing bugs then they're welcome to do so. > > - create a release checklist wiki page on Github > > You already did this tho I have some reservations about duplicating what is mostly the same content (as the original is in a doc in the repo source code). Releases are really just internal projects for the core team. The main activities are packaging everything up – e.g. adding to the CHANGELOG, creating the release packages – and QA-ing all of the core features on each of the three supported platforms. Our checklist wasn't secret before but adding it to the wiki makes it editable by anyone, which isn't true – the release process isn't something we're voting on. It's something the members of the core team agree to do. This seems doable to me but Id like to have some feedback: > > 1. Should we add more? > 2. Are you supporting a rapid release cycle? (less issues fixed but > frequent releases) > 3. Should 0.8.2 have even less? If so what should be moved to 0.8.3? > 4. Out of these tasks what are the ones you want to be assigned to? > > My feedback for the numbered items above: 1. Should we add more issues to the current milestone? No, but yes maybe. For the foreseeable future, anything that's working, QA-ed, and approved by the core team will be added to the milestone for the next release. 2. Yes-ish. The current bottleneck is QA-ing each release on each platform by the core team members; the other release process tasks also require a significant amount of time and, perhaps more onerously, coordination and even some amount of synchronization. We could definitely do a lot of stuff, maybe all of it, asynchronously, but it still requires a bit of work. Something that just occurred to me is that maybe adding (or fixing or re-implementing) a feature so users can run an 'edge' version would be just as good as more-frequent releases (with less, or no, QA). I created an issue for the 'edge' version feature if anyone is interested. <https://github.com/LightTable/LightTable/issues/2251> 3. Maybe a little. I still think the upgrading fix should be the core component of the next release and I'd be willing to publish the next release with just that, if nothing else is finished around the same time. But, to repeat myself a bit, we can and will include anything else that's finished whenever we (the core team) decide we want to publish a new release (whenever that is). 4. We are a self-assigning project. Anyone and everyone is welcome to step in or step up and work on anything in which they're interested and motivated. We (the core team) are committed to reviewing everyone else's contributions but we (individually) have our own interests and priorities so we need to be convinced to work on something. > * on that type of issues once you have two +1 and one champion it gets > added to the next milestone (inspired by ESLint guidelines) > > Given that our bottleneck is people willing to contribute the requisite work, in the form of working and QA-ed code, I'm not willing to commit to something like this. -- You received this message because you are subscribed to the Google Groups "Light Table Discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
