<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>I like the idea of getting more tests in there now in part so that it can feel like a more regular practice to add tests whenever we add new features.</div></div></blockquote><div><br></div><div>Looks like we are at 45% test coverage already--not bad! </div><div><a href="https://gist.github.com/sbenthall/05f585518cac8e27039a7c1b5da11a62">https://gist.github.com/sbenthall/05f585518cac8e27039a7c1b5da11a62</a></div><div><br></div><div>There's this old ticket calling for 60% test coverage, which seems like a good target for the 0.2.1 release:</div><div><a href="https://github.com/datactive/bigbang/issues/38#issuecomment-403527036">https://github.com/datactive/bigbang/issues/38#issuecomment-403527036</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>I like the idea of adding API documentation, but mostly only if we can generate that from inline docstrings, as I'm not confident at this point that we can keep completely separate documentation pages up to date. I recognize we might need a page or two of overview documentation that would be separately written, but otherwise I think we can just use tools to generate docs and then make a habit of keeping the parameter explanations up to date in the code itself.</div></div></blockquote><div><br></div><div>+1  </div><div><br></div><div>There's quite good support for docstrings in Python, and well-establish tool chains for publishing docs generated from them to the web.</div><div>The principle benefit of publishing docs on the web is that they can be found by search engines.</div><div><br></div><div>I haven't ran the script yet, but there are utilities for finding docstring coverage. Issue created here:</div><div><a href="https://github.com/datactive/bigbang/issues/341">https://github.com/datactive/bigbang/issues/341</a><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>I'm not at all clear on what would be necessary for the Python 2 -> 3 migration or what benefits that would bring us, so I hope you can take the lead on that Seb, if indeed it's important for future progress.</div></div></blockquote><div><br></div><div>I can take the lead on this.</div><div><br>It's something we need to do to keep up with the dependent packages.</div><div>Not all of them will support Python 2 in the long term.</div><div>It will also make it easier to install, since most new Python installations will be Python 3 going forward.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>What do others think? If this makes sense, should we start opening issues to track these tasks?</div></div></blockquote><div><br></div><div>Already on it! Milestones sorted out here:</div><div><a href="https://github.com/datactive/bigbang/milestones">https://github.com/datactive/bigbang/milestones</a><br></div><div><br></div><div>Now the question is how to get the work done.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div>On Jul 3, 2018, at 7:02 AM, Sebastian Benthall <<a href="mailto:sbenthall@gmail.com" target="_blank">sbenthall@gmail.com</a>> wrote:</div><br class="gmail-m_-168569113941677639Apple-interchange-newline"><div><div dir="ltr">Hello!<div><br></div><div>Feeling fresh from the 0.2.0 release, I'm thinking about how to keep momentum. It was, really shockingly, over three years between the first two releases, and that's really not right. Research [1] has shown that after three releases, a project is much more likely to be a 'success', not getting abandoned.</div><div><br></div><div>There is also clearly a lot of ways to polish BigBang that are not deeply technical. </div><div> - We made a lot of progress on the notebooks in the last release, but there is still lots more to do. For example, there's no reason why we shouldn't have notebooks demonstrating how to answer each of Corinne's questions from her recent thread. </div><div> - There's also lots we could do to improve documentation. We should be publishing the API docs to a website like <a href="https://readthedocs.org/" target="_blank">https://readthedocs.org/</a></div><div> - We have a few automated tests, but not thorough test coverage. We could improve that.</div><div><br></div><div>I propose we make this kind of polishing work the goal of the next, <i>0.2.1</i> release. This would be a small patch release on the existing one, with no major functional changes.</div><div><br></div><div>A reason why I'm proposing this is that in my mind, the most urgent big update needed to BigBang is conversion from Python 2 to Python 3. That will involve a lot of tweaks across the entire system. Automated test coverage and good documentation of the existing functionality is important to make sure we don't lose quality and introduce new bugs when making that upgrade.</div><div><br></div><div>What say you?</div><div><br></div><div>Thanks for reading,</div><div>Seb</div><div><br></div><div>[1] <a href="https://mitpress.mit.edu/books/internet-success" target="_blank">https://mitpress.mit.edu/books/internet-success</a></div></div></div></blockquote></div></div></div></blockquote></div></div>