Getting started on organizing all the topics discussed, first step the Mayan EDMS design doc, here is the links:
https://docs.google.com/document/d/1TUwWFW5d9lZcoHBKNjdkVwqrqiO1zJhtFDOUU9Tvaf8/edit On Tuesday, December 18, 2012 5:40:08 PM UTC-4, Lachlan Musicman wrote: > > <Moved into this thread to provide clarity to those that come after us> > > On Wed, Dec 19, 2012 at 8:21 AM, Roberto Rosario > <[email protected] <javascript:>> wrote: > > Thanks! I'm still going through your messages thinking how to best > organize > > all the topics mentioned in an open way. A Wiki on github or on > > dev.mayan-edms.com comes to mind. > > And that's the rub - it's quite difficult to imagine where to start, > how to go about it and what software is best to do it. > > They are quite difficult questions to answer correctly for any given > project. I would suggest we run with your original idea of a GDoc. > > Then we do simple descriptions: > > A Document is a Model, it has fields x, y, z and methods a, b, c. > I normally then describe the non-obvious fields ("this can be > disability can be NullBoolean as people may choose not to answer the > question") and the non obvious methods ("we override save to slugify > the name for slug field") > > This way we can see the obvious weirdnesses - like what is the > mark_indexable()? > > etc... > > It can be a slog, but will be well worth it, especially for clarifying > ideas in your own head, and making an easier pathway into the code for > others. > > cheers > L. > > On Tue, Dec 18, 2012 at 1:41 PM, Lachlan Musicman > <[email protected]<javascript:>> > wrote: > > Of course, I've managed to skip over some other initial thoughts I've > > had as well: > > > > - I think that the best thing to do will be to move the dev branch to > > dev-old and start a new dev based on the current master > > - that way people can start by doing small tasks almost immediately - > > as I was reading through the code I noticed some quick fixes that I > > could have done but didn't > > - regards the haystack/search: 1. Why must the search solution be > > python? I set up Solr (cluster friendly) quickly and easily using > > haystack. Is search something that we don't integrate, but instead > > provide "easy documentation on how to set up for Solr/Whoosh"? Also, > > since you are using pbs anyway, surely a cron job is easy enough to > > automate? > > - moving to newer Django has other possibilities and advantages than > > just CBV. New layouts (and therefore paths) is quite handy. Plus, the > > deprecated stuff.... > > > > - Why a design doc? The first thing I wanted to work on was updating > > the requirements, and for some reason I started with > > djangorestframework -> rest_framework. Which I did. But without being > > able to see where the serialisation was meant to work or what it was > > used for, there was no way to test if I'd broken something.... > > > > Anyway, just a bunch more thoughts - cheers > > L. > > > > On Tue, Dec 18, 2012 at 10:23 AM, Lachlan Musicman > > <[email protected]<javascript:>> > wrote: > >> Roberto, > >> > >> Hey thanks for the big reply. Ok, I understand more now, and I spent > >> an hour or two last night trawling the git logs (offline), the file > >> tree and trying to get dev to run. > >> > >> I submitted a pull request late last week but removed it Monday > >> morning after I read the in docs (I only remembered I had sphinx > >> installed on Sunday night...) about the gitflow/git branching model. > >> > >> I think a shared doc might be a good idea, can I give a little > direction? > >> > >> Obviously Mayan is now quite massive in terms of files and apps. It's > >> quite hard to get a full picture or holistic view of the software > >> apart from the broad "Document Management System" description. I am > >> also somewhat unfortunate in that I don't have a use for it at the > >> moment nor have access to a large install to readily see workflows, > >> errors and obvious needs. > >> > >> So I think a design document of sorts will be handy, so there can be > >> an understanding of what the project is aiming for, and how it's going > >> to get there. This will be the pinnacle of the documentation, since > >> from it all else flows. It will be significantly easier for others > >> like myself to help if we have a guiding light (for want of a better > >> term) showing us the way. > >> > >> For instance, can I recommend/request a UML or mind map diagram of how > >> all the apps inter-relate? You may find that there are too many for a > >> single diagram and that it needs to be broken up a little bit - maybe > >> even one diagram per app. For most apps, it's obvious, ocr for > >> instance. > >> > >> But the subtleties of how each app interacts with other apps is not > >> immediately obvious for all of them, and would be a great help. > >> Obvious examples are the Singleton model - what uses it? Why has it > >> been abstracted? etc. Registration - what is it used for? Is it part > >> of the auth/perms structure? > >> > >> Then there are other factors - like where do you imagine a major > >> refactoring to take place? Is the new User model available in Django > >> 1.5 worth utilising? Should we aim to refactor into Dj1.5 to use it, > >> then drag the rest of the code kicking and screaming into line? > >> > >> My initial thoughts when trying to get Master to run were: > >> 1. - let's clean up the easy pickings: updating all the non-Django > >> requirements, like djangorestframework->rest_framework is a good/easy > >> example. > >> 2. - let's move the code to Django 1.4+, probably worth going to 1.5 > >> since it's almost out and this might take some time > >> 2.a. -- in particular: whenever possible, move function based views > >> to class based view. This is one good reason for the design doc - > >> there are a lot of abstracted ideas (eg, in documents.models) that > >> aren't easy to quickly unravel, but could probably be moved to class > >> based views very easily. > >> 3. Start implementing new features. By definition a new feature is > >> something that currently doesn't exist or doesn't work. IE get the > >> basics working on up to date software, documenting as we go, then > >> push forward with greater understanding. > >> > >> I am aware that none of this is easy or quick, and that people have > >> jobs, families and lives to live. But at the moment "what to do next" > >> is quite opaque. > >> > >> For the record, I'm not so good at testing, and since I find the code > >> base so large and difficult to follow, it's hard to know what > >> behaviour to expect (and hence to test for) - another reason for some > >> good design documents. > >> > >> Anyway, let's start a Gdoc and get started? > >> > >> cheers > >> L. > >> > >> > >> On Tue, Dec 18, 2012 at 7:36 AM, Roberto Rosario > >> <[email protected] <javascript:>> wrote: > >>> Yeah, this is my first attempt at using Haystack and I'm a bit lost at > the > >>> moment, thinking about adding back the direct to database search > method > >>> until I'm more familiar with Haystack. I also don't like the idea of > having > >>> to schedule a job just index the search file, and the default Python > based > >>> search backend for Haystack is not cluster friendly. > >>> > >>> There was a rough roadmap online for a while but other commercial > software > >>> were using it to get ideas for improvements on their products and not > >>> contributing back in any way to Mayan, so I took it down, and instead > >>> working on features directly requested by users of Mayan. > >>> > >>> I could really use help with documentation and unit tests. > >>> > >>> My initial plan was to keep all the improvements on the development > branch, > >>> and work only on bug fixes for the master branch (the stable version). > But > >>> since the development and master branch have diverged so much and > since the > >>> development branch is still to unstable to call it Mayan 1.0, my new > >>> approach is going to be to bridge the gap by moving code from > development to > >>> master. If you or anybody else wants to dig deep into the code, the > new > >>> priority is getting as much code moved to the master branch starting > with > >>> the navigation, icon rendering and app registration code; code cleanup > and > >>> organization (moving links to a links.py file as well as an icon.py > file, > >>> remove isolated functions and turn them into simple classes with > contextual > >>> methods) is also a big priority to make it easier for developers > writing 3rd > >>> party apps for Mayan. > >>> > >>> The changes you noted are a good example of the kind of clean ups > taking > >>> place: the api.py file was removed from most apps and is only present > if the > >>> app exposes an API for external use by other apps; the register_links > method > >>> was removed as links are now a classes (instead of simple non > contextual > >>> dictionaries) and registered as soon as they are created only bound to > a > >>> view or object class later on with the bind_link function; icons are > also a > >>> class, this allows for switching icon sets very easily instead of > depending > >>> on the Silk icon set text names. > >>> > >>> If there is interest I can write a shared GDrive document to > coordinate > >>> efforts. > >>> > >>> --Roberto > >>> > >>> On Sunday, December 16, 2012 11:57:07 PM UTC-4, Lachlan Musicman > wrote: > >>>> > >>>> Hola, > >>>> > >>>> I've forked the dev branch to start working on the code base, and was > >>>> after a few tips: > >>>> > >>>> 1. When running ./manage syncdb --migrate --noinput to get started > with > >>>> testing, I'm getting Haystack errors. I've managed to squash a > couple, but I > >>>> don't want to stray too far from the herd - there seems to be a > missing > >>>> HAYSTACK_SITECONF file? should it be > >>>> HAYSTACK_SITECONF='apps.dynamic_search.search_index' > >>>> > >>>> 2. Is there a roadmap that is being followed or a list of "TODOs" > that I > >>>> could use for guidance on what to do next? I've got a couple of > ideas, but > >>>> don't want to tread on toes... > >>>> > >>>> cheers > >>>> L. > >>>> > >>>> > >>>> -- > >>>> ...we look at the present day through a rear-view mirror. This is > >>>> something Marshall McLuhan said back in the Sixties, when the world > was in > >>>> the grip of authentic-seeming future narratives. He said, “We look at > the > >>>> present through a rear-view mirror. We march backwards into the > future.” > >>>> > >>>> http://www.warrenellis.com/?p=14314 > >>> > >>> -- > >>> > >>> > >>> > >> > >> > >> > >> -- > >> ...we look at the present day through a rear-view mirror. This is > >> something Marshall McLuhan said back in the Sixties, when the world > >> was in the grip of authentic-seeming future narratives. He said, “We > >> look at the present through a rear-view mirror. We march backwards > >> into the future.” > >> > >> http://www.warrenellis.com/?p=14314 > > > > > > > > -- > > ...we look at the present day through a rear-view mirror. This is > > something Marshall McLuhan said back in the Sixties, when the world > > was in the grip of authentic-seeming future narratives. He said, “We > > look at the present through a rear-view mirror. We march backwards > > into the future.” > > > > http://www.warrenellis.com/?p=14314 > > > > -- > ...we look at the present day through a rear-view mirror. This is > something Marshall McLuhan said back in the Sixties, when the world > was in the grip of authentic-seeming future narratives. He said, “We > look at the present through a rear-view mirror. We march backwards > into the future.” > > http://www.warrenellis.com/?p=14314 > --
