On Sat, Oct 19, 2019 at 2:25 AM Vitaly Potyarkin <sio....@gmail.com> wrote: > It's a backup mechanism for GitHub issues and pull requests that creates > human-readable issue archives in HTML - ready to be served as a static web > site. The project is written in Python and works by extending Pelican > static site generator, it provides Makefiles for quickly starting with demo > configuration.
A good plan. I'm personally (and currently) happy with GitHub, but I'm aware that not everyone is, and of course we don't know what the future holds. > What do you think of the project idea? Would that be useful to you or > anyone you know? Merely by existing, it has value. (Although it would have to be perpetually maintained in order to retain that.) It proves that use of GitHub Issues does not imply that you're locked into the platform, and as such, it's the elimination of an argument against the platform. > Also, if you have time, any feedback on code/architecture would be very > appreciated! You mention a persistent Storage, merely in passing. I want to see more about that. If that storage format is a nice easy thing to work with (eg a set of JSON files), and is a documented and forward/backward-compatible format, it could become a de facto interchange format. Even though THIS project never claims to be able to push back into any issue tracker, some OTHER project could pick up that side of it, and voila, you have a straight-forward backup or transfer format. What are the consequences of using the AGPL for this? If this project is used to create a viewable/searchable issue display, does that mean that the issues themselves are covered by the AGPL, or are they counted as data? I'm hoping it's the latter, but IANAL and I wouldn't want to get bitten by something unexpected. ChrisA -- https://mail.python.org/mailman/listinfo/python-list