Idea/Proposal: Create a Part Update Schedule


Re: Idea/Proposal: Create a Part Update Schedule
#8
I wouldn't be against a script that periodically takes parts that have been certified + admin approved and generates a new "Official Release" to be downloaded and generates a page such as this. It's basically (as far as I understand) what happens anyway.

Here's how I see it:
Automation is good. Periodic automation is fine. Asking volunteers to do work for free by yesterday is bad.



As a counterargument to the above posts, I would like to mention the OpenBSD project which I love and hold dearly. Its developer base is quite similar to here. IIRC: 80ish developers with accounts, 15ish active, and everything is done for free by volunteers (except for the lead guy who has dedicated his life to it).

It has had a six month release cycle as long as it has existed and it works quite well for it. One good thing about the regular release cycle is that each time they produce CDs, T-Shirts, and Posters that are sold to pay for hardware/electricity bills and some to support the main dude (doesn't really apply here). By no means are any of the developers forced to complete their work by a certain day, however they are encouraged to test the system to hopefully catch any bugs that may have slipped through the peer-review system.

Most if not all of the active developers personally run -current, the evolving development version, like those of us who keep Unofficial/ up to date, so it's not a big deal to have your patch (or in this case part) need to wait till the next "official release" (which, as far as I can tell, to the developers has a largely superficial meaning, except the joy of being reminded of how much they've collectively achieved).

You may be wondering why I bring this up. During "release time" the main dude (HERE: PT-Admin) encourages developers to pause efforts on adding new functionality (HERE: authoring new parts). Instead, developers focus on testing (HERE: reviewing/certifying). Even more applicably, durring this time, there is a general aire of "I want my patch (HERE: part) to be in the next release because blah blah blah," which is quite healthy for the community.

As a personal example of how this applies to LDraw, yesterday I was working on a model that used a 59443 and couldn't find it. I downloaded the latest unofficial parts, and the PT was already two steps ahead of me. I thought it a shame to need to inline the part in each model just to be OMR compliant since this part had shown up quite often in recent sets, therefore I thought it should be important to be in the next release. (I hadn't noticed that it was already admin certified.) If I were a parts author (which I intend to become pending an increase in available time) I would want to make sure to get this part included in the next release so that I wouldn't need to submit the model to the OMR with the part inlined, and knowing that the next "official release" would be generated in 4 days would encourage me to review it. I would certainly not feel "forced" to do anything, but knowing that, in order to not need to inline the part, I would need to get it certified/approved soon.

This could be accomplished by the PT admin just saying, "Hey everybody, I'll take all parts certified/approved by the 31st and put them in the next update." However I believe this is the wrong approach because part of me would want to "just get it approved in time" instead of the rest of me wanting to make sure it's done properly no matter how long it takes.

A better approach would be, "Sure, the update will be generated in 8 days, but also again X months after that (or whatever interval should be decided)" instead of "After the 31st, nobody knows how long it'll be." So it would not be such a big deal to miss the next update, because I know I can take the time I need to do things properly and have it in the next regularly scheduled update, and I have a guarantee that I won't get the part certified and still need to keep it inlined it for the next nine months for the model to be able to be viewed properly by those without the latest unofficial parts.

This is said by someone who has written code for OpenBSD but not submitted parts to the PT (yet), so take the above all with a large grain of salt as my view is definitely skewed by personal observation/experience outside of LDraw. I do not pretend to know the right solution (or even if the current solution is perfect already), I'm just giving my perspective.

EDIT: I forgot to mention that each OpenBSD release always has some general theme (both literally in terms of the art released and figuratively in terms of what the developers have generally focused their efforts on). For example, recently there has been an effort to improve multithreading capability/efficiency and handling of large memory/storage capacity, much as we have recently focused on patterned parts. This "Hello. I'm trying to create minifig patterns." has lead to many patterned parts for the next release, much how it often happens in OpenBSD where the community sometimes picks up on an individual's personal project.


TL;DR - I humbly believe releases should be {mostly/entirely} automated and should happen on some fixed interval, requiring no extra work and imposing no deadlines on volunteers, but providing a regular milestone inspiring some parts to be prioritized if authors so choose as has been proven effective in the LDraw community here and here and throughout its history (as far as I can tell).
Reply
« Next Oldest | Next Newest »



Messages In This Thread
Re: Idea/Proposal: Create a Part Update Schedule - by Jean-Philippe Ouellet - 2011-12-27, 7:33

Forum Jump:


Users browsing this thread: 5 Guest(s)