VNDB Development poll
|#1 by yorhel|
2018-06-02 at 09:57
|I realize that contributing code to VNDB has never been a very pleasant experience. Part of this is intentional, since low-quality drive-by contributions (which are very much the norm in open source) will only end up creating more work for me, and increasing the barrier to contribution is a time-proven method of filtering out low-quality contributions. Unfortunately, this has the side effect of strongly discouraging *anyone* from helping out, which doesn't really foster a healthy community either.|
There's already been work on improving the setup of a development environment. with the introduction of a Docker config. That ought to help, but it's only a small part. I've been thinking about a few other ways to make code contributions easier, and am curious to hear about opinions here.
(Disclaimer: I tend to have strong opinions on some of these proposals, and I won't promise to actually implement all suggestions)
|#2 by aquahorse|
2018-06-02 at 10:05
|Voted for first choice.|
|#3 by wakaranai|
2018-06-02 at 13:03
|lol, i've chosen 3 most popular options without looking at the results.|
"comprehensive" database dump may be an overkill, but it really was a nuisance to fill local database with placeholder entries just to test things.
|#4 by yorhel|
2018-06-03 at 06:12
|I suspected there would be some people who'd insist on Github, considering how much that is being evangelised in some communities, but I'm glad it's not so bad here. So I moved VNDB to Gitea, see t10749.|
I'll work on that database dump, because I agree that it's a good idea in any case. I wrote down some thoughts about its implementation.
As for documentation, I'm not entirely sure where to get started on that, either. I plan to use the Gitea issues to have a to-do list categorised by ease of implementation, so there's at least a starting point. I suggest that, if anything is unclear or is lacking documentation, this is also handled via issues.
|#5 by aquahorse|
2018-06-03 at 07:05
|And modified user tags, info on novels or screenshots? Do users need to send you their info on this?|
|#6 by yorhel|
2018-06-03 at 17:40
|And there's a partial database dump now.|
|#7 by avunyx|
2018-06-03 at 19:32
|I anticipate this poll has reached a certain deadline, as various new features are already being added, but still, is there any reason to fill in the survey now? And is there a way to mark a poll as expired, besides deleting it?|
|#8 by yorhel|
2018-06-03 at 19:36
|This poll isn't much more than a way to give me a general feeling of where I should allocate my efforts - it's not like the outcome will fully decide what is going to happen. So by all means, keep voting. :)|
|#9 by avunyx|
2018-06-03 at 19:48
|I see. Thanks for the additional explanation. It's great to see devolopers and users working together so closely. Will definitely add my vote in :)|
|#10 by eacil|
2018-06-04 at 02:36
I suspected there would be some people who'd insist on Github, considering how much that is being evangelised in some communities, but I'm glad it's not so bad here.All the more reason to not use it now that micro$oft decided to acquire it.
|#11 by 3db|
2018-06-15 at 02:43
|I think there's a combination of things that present a high bar of entry to making contributions to VNDB. Many of these are already addressed or are being addressed, and from your post some of these things you may see as positives rather than negatives:|
-- VNDB is difficult to set up. This was probably one of the biggest hurtles to developing for VNDB which is now largely solved by the new Docker solution.
-- VNDB does not have a decent set of test data. Once you set up your own instance of VNDB you would have to spend time manually entering data into it in order to be able to perform meaningful testing on whatever feature you wanted to develop. This was a time consuming task. This is solved by the new DB dump.
-- Use of Perl is not as widespread as it once was. There are a few different sub-hurtles that need to be cleared in order to successfully develop on VNDB. First is knowledge of Perl which seems to be going out of style. The likelihood that a developer who wants to contribute to VNDB knows the language isn't great. Those without Perl experience will need to learn it and learn it well. The Perl syntax used within the VNDB code base can be difficult to pick up for people who don't work with the language regularly.
-- The VNDB code base is not easy to understand. I contributed a small amount maybe 10 years ago and the code base has grown in both size and complexity since then. I revisit the code every so often out of interest and it can often be difficult to navigate. Application logic for different pieces of the site can be spread around among the handler code, inside database triggers, or within multi. TUWF is efficient but the concept of building a response using subroutines that generate HTML entities is not common and can make it hard to visualize what the handler output will look like. There is little documentation in the code to help figure out what the more complex sections are trying to accomplish. Maybe some of this can be addressed in the Utawarerumono update.
Overall I think the prospect of jumping into the VNDB code with the intention of contributing can be daunting, but it seems like steps are being taken to help reduce the amount of effort needed to get started. Still, it takes a lot more time and effort to piece apart and reason about the VNDB code than it does for other projects. That's not necessarily a bad thing, it does ensure that any contributions will probably be of reasonable quality as anyone submitting a patch or PR has likely spent a decent amount of time with the code in order to understand how it works. The VNDB code works very well too, I have no doubt that VNDB is mind-blowingly efficient.
I'm excited to see what happens with the Utawarerumono work. Keep on making the best VN DB site in existence =)
Edit: I'm going to leave the references to Utawarerumono in as they amuse me. You can probably figure out what I was referring to...Last modified on 2018-06-15 at 02:47
|#12 by yorhel|
2018-06-15 at 06:34
|@3db: Good to see you're still around, and thanks for the feedback!|
Regarding Perl: I have been trying out other languages and frameworks in the past two years, and have seriously considered writing v3 in a different language. But after all that research, I came to the conclusion that Perl is, in fact, not a bad language at all. I'll never understand OO-heavy languages (my brain just isn't wired that way), functional programming languages have the same contribution barrier (or much worse, in the case of Haskell), and it's really hard to beat Perl in terms of productivity.
Regarding code structuring, it is my intention to improve this in v3, but I'm finding this surprisingly hard. I believe the switch to SQL::Interp (getting rid of the mess in VNDB::DB::*) and much better utilities for form processing will improve things, but overall code structure is still not an easy problem to solve. It doesn't help that VNDB is genuinely complex in certain aspects. I could really use help with v3 to identify places where the code is complex or unclear and to see if it's possible to restructure that for clarity. (Though I have my doubts that there's a good solution for the HTML generation thing - templates suck for highly interactive things.)
You must be logged in to reply to this thread.