- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Export workflow, template format proposals (discussion)
by Johan Engelen 03 Apr '14

03 Apr '14

Hi all, A quick note, the functionality of saving to a file (possibly a PDF) without setting it as document file is already there. It's called Save a Copy... in the menu. -Johan ----- Reply message ----- From: "Bernard Gray" <bernard.gray@...400...> To: "Martin Owens" <doctormo@...400...> Cc: "Inkscape Devel List" <inkscape-devel(a)lists.sourceforge.net> Subject: [Inkscape-devel] Export workflow, template format proposals (discussion) Date: Thu, Apr 3, 2014 07:39 On 3 April 2014 13:46, Martin Owens <doctormo@...400...> wrote: > On Thu, 2014-04-03 at 11:22 +1100, Bernard Gray wrote: >> My proposal is actually to support both these workflows - add the File >> -> Export to... PDF menu option, but leave the "Save As... -> PDF" >> option intact. > > Sorry I wasn't clear. This is my proposal also. > > I would not like to see a new menu item though. Exporting a specific > type should be something the export dialog takes care of, so exporting > to eps, pdf or something else. > > The big difference between export and save as, is that save as sets the > document filename to this new filename and export should not. Great, we're on the same page - I'm not fussy as to how it's implemented in the menu. Gimp currently provides two Export options in it's file menu, "Export", and "Export As...": * Export As... takes you to a file picker dialog, where you can choose the location and format of the exported file * If you haven't exported the document already, the "Export" button does the same thing * Once you have exported the document, it remembers the last file you exported to and the "Export" button title changes to reflect this, ie "Export to <file>.<extension>" This would require the addition of a new menu item though. If you want to avoid this would you prefer to just go with something similar to the Gimp "Export As..." button/functionality? > Martin, > ------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 2

Export workflow, template format proposals (discussion)
by Bernard Gray 03 Apr '14

03 Apr '14

Hi All, It's been a long time (my alias is cleary) - We're beginning to see inkscape get some traction in our company as a tool for non-designers to make small changes to templates/documents that our designers create. An example scenario: Our HR Dept does Job Vacancy releases. These job vacancy documents have fairly standard elements, and the vast majority of changes that the HR guys need to make are as simple as changing the date, or location. The workflow I'm looking to introduce is: the Designers create a template, HR can then take that template, make minor text changes, export to PDF and distribute. There are two niggles in the way inkscape handles this process, and I'd like to at least open up some discussion on resolving these niggles. 1st Niggle: Exporting to PDF is a "Save" operation, not an "Export" operation After they've made some changes, the users must remember to save as SVG first before saving as PDF in order to maintain a compatible "source" document. They also have to remember that after saving as PDF, they are no longer working on the source document. Proposal: Expand the "Export to Bitmap" File menu item to include PDF, and potentially other formats that are not suitable as a "source" document ie they can't preserve an adequate level of info - layers, objects etc By doing this, The Export action creates the PDF (or non-source suitable) document, and any subsequent modifications are still saved to the source SVG document without any further opening/closing/saving over existing docs. Gimp recently introduced this idea I believe. 2nd Niggle: The current "Templates" handling involves maintaining documents in a dir under the inkscape profile dir. This requires some bespoke SOE handling for multiple users to get access to multiple templates. Proposal: Introduce an "inkscape template" file extension in a similar fashion to popular office suites (.svgt?). The file is no different to a standard inkscape svg, the only difference would be that when you go to Save the document for the first time, it forces you to use the Save As... dialog so you don't overwrite the template. This would allow users to keep templates *anywhere*, and won't require any significant training or support to make sure there's no accidental clobbering of the template documents. I'd be keen to hear people's thoughts, and I realise this may be better as two separate discussions. My programming skills are fairly atrophied these days, but I would definitely consider having a crack at patching something. Paying for the features either in the form of a project donation or by specifically hiring resources are also possibilities. Thanks for your consideration, Bernard Gray

2 6

Export workflow, template format > proposals (discussion)
by Jelle Mulder 03 Apr '14

03 Apr '14

Hi all, My two cents on this ongoing discussion. 1.) Export of non native file formats Everything that is not native Inkscape should go to an export/import. I think Bernard's case gives a great rationale for doing it that way. Indeed it takes less brain effort to just export and import and keep the work file in InkSVG format. I'm pretty used to Inkscape, but I've had my moments of doubt. I can imagine that for people less knowledgeable will make the wrong decision here. 2.) Template directory of choice - Template extension .svgt It would be a really nice thing if you could put your templates in a directory of choice at least, so it would be easier to keep a selection of templates you'd actually use in it. Or in case you want to make changes to existing templates copy them to a new directory and edit them there without fear of messing things up. Using the export again, it would be easy to save a file as template in the directory of choice, rather than just save the file and mess up the original template. Otherwise, save the thing as a new file and force naming it with a blank name. Using an extension like .svgt feels a bit over the top. Next we'd have .svgr (resource file) etc. Whereas it is all SVG content with a few extra namespaces. Having a more logical way of organising your files seems more to the point to me. Cheers, Jelle On Thu, 03 Apr 2014 08:22:59 +0800, <inkscape-devel-request(a)lists.sourceforge.net> wrote: > Message: 8 > Date: Thu, 3 Apr 2014 11:22:51 +1100 > From: Bernard Gray <bernard.gray@...400...> > Subject: Re: [Inkscape-devel] Export workflow, template format > proposals (discussion) > To: Martin Owens <doctormo@...400...> > Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> > Message-ID: > <CA+Br8tPvQHPu3NeSeR7R1hkJL5-75rQ3FykAW0Kf4tDZDwja+A@...401...> > Content-Type: text/plain; charset=ISO-8859-1 > On 2 April 2014 21:36, Martin Owens <doctormo@...400...> wrote: >> On Wed, 2014-04-02 at 13:06 +1100, Bernard Gray wrote: >>> I'd be keen to hear people's thoughts, and I realise this may be >>> better as two separate discussions. >>> My programming skills are fairly atrophied these days, but I would >>> definitely consider having a crack at patching something. Paying for >>> the features either in the form of a project donation or by >>> specifically hiring resources are also possibilities. >> >> Hi Bernard, >> >> I think the solution might be to think of inkscape as the template >> creator and renderer. >> >> So one can run inkscape from a script or command line in order to turn >> any svg into a pdf. This is useful for keeping things in svg until the >> last part of the process and you can automate this. I've seen solutions >> that watch a directory for svg files and render pdf files automatically. > Hi Martin, > Thanks for the reply - I imagine that scripting is a common (and for > us at least) a fairly simple option to implement. > In my users case though, this goes back to limiting the locations > where they can store the files, and I'm trying to remove this > restriction on them. It'll also cause us support issues if the service > isn't running, or they move the files and it stops working etc. The > least added maintenance/support we the IT team have to do, the better. > Like it or not, you guys have done a great job of the GUI interface. > It's very accessible, and users can go from novice to functioning in a > matter of minutes. For this scenario specifically, I'd like to > leverage this feature > >> The other option is to print to pdf. Not sure if it's the same for >> inkscape's renderer or not though. > Great idea - for the HR guys, they're running windows so I'll check to > see what print dialogs/renderers we can get access to there and that > might be an adequate workaround for now. > >> For data entry. i.e. fixed fields. We could do more work there for sure. >> We don't really have a way of specifiying parts of a document which are >> configurable and parts that aren't. I don't think SVG2 is going in that >> direction either (please surprise me with a correction Tav) > Don't worry about this bit - to create this feature I've just added a > layer of non-editable elements, and locked that layer. Then all the > editable elements go on a new, unlocked layer. > >> Overall I think the work might be done with smaller scripts. Although >> we'd certainly appreciate the investment in inkscape to improve the save >> and export design. In my designs, save would be for any file. It would >> default and prioritise svg/plain svg etc, but if you selected pdf or png >> it would open the export dialog setting that file. Making it a two entry >> flow rather than two single flows. > That's an interesting take on it. I was thinking that we could > potentially leave both flows in (ie adding the file types to the > Export menu, but not removing them from the Save menu). I guess it > gets complicated here because inkscape has the ability to handle PDF > file types directly (opening and saving), so ideally you'd want to be > able to save back to that (and similar) file types directly where > applicable. > One of the reasons I proposed the Export to... option and keeping the > two flows separate was to maintain consistency with the workflows of > other similar tools. I just realised that my knowledge of other tools > (adobe cs suite for example) is fairly limited, so I just went and had > a chat to the designers next door to see what is actually done - > Illustrator: No "Export to... PDF" option, only "Save As...-> PDF". > This behaviour is the same as inkscape currently > InDesign: Has "Export to... PDF" option, but no "Save As... -> PDF" > So it's no clearer > My proposal is actually to support both these workflows - add the File > -> Export to... PDF menu option, but leave the "Save As... -> PDF" > option intact. > This gives the opportunity for a user to not have the source file > changed from underneath them via a save operation *if they choose* and > significantly reduces the risk of it happening inadvertently, but > leaves the scenario where you can change the working file to a > different format deliberately, *if you choose*. > It can also open up the opportunity for exporting to other bitmap > formats (like jpeg which I occasionally find myself having to take and > extra step to convert to from time to time) > >> There's little reason to consider pdf options and png options to be >> somehow different. > The options for exporting aren't different per se, but the concepts of > Exporting vs Saving *are* very different. That's the key issue I'm > working to resolve. > >> Best Regards, Martin Owens > Any thoughts on the svgt(emplate) file proposal? I raised the idea > with the designers, and they really liked it. Apparently they are > constantly fixing "template" files that have been accidentally > overwritten because someone forgot to take a copy first, or remember > to use Save As for the first save.

1 0

tessellation maker - Escher inspired
by Mark Schafer 02 Apr '14

02 Apr '14

Saw this great project. Would make a great plugin for inkscape. Posting for the future... http://danceswithferrets.org/geekblog/?p=154

2 3

Text Blocks as Templates
by Martin Owens 01 Apr '14

01 Apr '14

Hi devs, I noticed filedialogimpl-gtkmm.cpp has been cleaned by Johan. I was wondering if there's any way to take big blocks of template like the kind used in this file and keep them in separate files. I'm aware that there are pre-compile and compile-time macros and other interesting ways to handle these things. Or a run time loader (reducing the size of the binary, but increasing load time?) The three templates are sizable enough to be seperate, so is it C++ that prevents us or is it just messy to do so? Thanks for your answers, Best Regards, Martin Owens

2 1

Windows build broken
by Johan Engelen 31 Mar '14

31 Mar '14

Hi all, The Windows build is broken. Possibly after rev. 13225? Error output: compile src/ui/dialog/pixelartdialog.cpp Make error line 304: problem compiling: src/ui/dialog/pixelartdialog.cpp: In member function 'void Inkscape::UI::Dialog::PixelArtDialogImpl::vectorize()': src/ui/dialog/pixelartdialog.cpp:414:65: error: no matching function for call to 'Glib::Thread::create(sigc::bound_mem_functor0<void, Inkscape::UI::Dialog::PixelArtDialogImpl>)' src/ui/dialog/pixelartdialog.cpp:414:65: note: candidates are: c:\devlibs/include/glibmm-2.4/glibmm/thread.h:228:18: note: static Glib::Thread* Glib::Thread::create(const sigc::slot<void>&, bool) c:\devlibs/include/glibmm-2.4/glibmm/thread.h:228:18: note: candidate expects 2 arguments, 1 provided c:\devlibs/include/glibmm-2.4/glibmm/thread.h:273:18: note: static Glib::Thread* Glib::Thread::create(const sigc::slot<void>&, long unsigned int, bool, bool, Glib::ThreadPriority) c:\devlibs/include/glibmm-2.4/glibmm/thread.h:273:18: note: candidate expects 5 arguments, 1 provided Thanks for the fix, Johan

2 3

Private implementations of widgets
by Alex Valavanis 31 Mar '14

31 Mar '14

Hello All, Just wondering if we ever came up with a coding style for the private components of our widgets and dialogs. Our GUI components, for example, the dialog in [1] contain many different Gtk widgets (rather than pointers/refs to widgets) and so we need to include lots of <gtkmm/*.h> headers in our GUI class definitions. If the embedded widgets were replaced by references to objects, we could just use forward declarations of the appropriate classes and then pull the header inclusions into the relevant .cpp files so it should improve our compilation times. Is there a reason why we don't do more of this already? AV [1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/ui/…

5 6

Rewrite of style handling code, code review requested.
by Tavmjong Bah 31 Mar '14

31 Mar '14

Hi all, I have rewritten most of the style handling code in style.h and style.cpp to use real C++ classes. I would like you all to review the code and give feedback. The code is available at: lp:~inkscape.dev/inkscape/style Background: I have found it quite difficult to add new properties to the Inkscape code as I try to implement SVG 2 features. The code in style.cpp is a convoluted mess. To add a new property, one needs to find a similar, already existing property and search through the code for it to find all the places where one should add code for the new property. This is quite error prone and time consuming. Following the advice in the book "Refactoring, Improving the Design of Existing Code" (thanks to the Inkscape fund for a copy), I started to refactor the code bit by bit, while adding a bunch of unit tests to style-testing.h. Scope: I've limited my changes to the following files: style.h style.cpp style-internal.h style-internal.cpp, style-enums.h (plus minor changes to color.h, id-class.cpp, Makefile_insert). There are opportunities for further refactoring but they require modifying code in other files, something I wanted to avoid doing until I got the basic refactoring done. Advantages: It is now quite straight forward to add a new property, especially if it fits one of the pre-existing models. It can be as easy as adding the property to the SPStyle class declaration in style.h, initializing it in SPStyle::SPstyle, storing its address in the std::vector in SPStyle::SPStyle, and adding an entry in the switch statement in SPStyle::read_if_unset (this last requirement, could possibly be eliminated). Not only will it be easier to add new properties, but it will also be easy to add new functionality. For example, it will be easy to add a variable to keep track of where a property is set (in a style sheet, in an attribute statement, or in a style-attribute), and write out the property in the same place. This is a requirement if we are ever to include stylesheet editing in Inkscape. Disadvantages: The code could be slower as there is more overhead in function calls. I've tried it out with a large file (the Tango icons) and don't see any measurable slow down. The code does use more memory. It appears to use about 4k bytes more per object (this is really hard to measure accurately). One thing to think about in the code review is how memory use can be reduced. (One possible place memory might be reduced is that it appears that in the rendering of Inkscape's icons, the instances of SPStyle that are created are not released. This means that around 4000 objects are being kept around.) Status: The code is mostly done. Here is a list of possible things to be worked on: Short term (all internal to the SPStyle and SPIxxx classes): * Finish SPColor class and use where appropriate ('color' and 'text-decoration-color'). * Memory use issues: Remove unneeded destructors. Check variable order (to insure minimal memory use). * Class Documentation * Move SPIPaint/SPIFilter HREF functions into classes * Find out why SPStyle::read() requires call to clear(). * Investigate using std::map instead of std::vector to allow removal of switch in SPStyle::read_if_unset(). A hash is already being used to look up the property so it is a more a question of memory usage than efficiency. Medium term (requires changes external to style code): * Update rest of code to use new SPStyle member functions. * Restructure 'text' (i.e. font info) to match other properties * Restructure SPIPaint/SPIColor to match other properties * Convert text-decoration-style to SPIEnum * Move sp_css_attr_xxxx functions to separate file. * Correct quoting in 'font-family' * Proper 'font' class * SPIColor: Enum for color format: hsl(), named color. Long term: * Keep track of where a property is set (style-sheet, attribute, style attribute) and reuse on write. * Proper 'ex' height handling * CSS3 Color (HSL) + named colors (i.e. no longer convert red to #ff0000) * CSS4 Color * Proper handling of SPIFilter::cascade() and SPIFilter::merge() * Dash array with units. * Release SPStyle instances after icon generation. * Check for code duplication between SPStyle classes and XML style handling. * Add the ability to choose shorthand or longhand property formats. Tav

6 9

Slides needed for LGM 2014 opening
by Jon Cruz 30 Mar '14

30 Mar '14

Hi guys, Pippin needs some slides for Inkscape to include in the LGM 2014 opening presentation. These can be about the state of Inkscape in general, or a preview of upcoming sessions (Tav's on SVG 2). They need to be 1024x768, and can have a bit of notes in a .txt to give the presenter some rough guidance. If we don't have something by tomorrow morning, I can rough out some myself... but they may not be pretty. :-) Thanks.

6 15

[RFC] Proposal for handling fundraisers and funded > development (Bryce Harrington)
by Jelle Mulder 30 Mar '14

30 Mar '14

Hello Bryce, Let me give my two cents on the proposal then. In general though I applaud the plan. Comments preceded by ** Cheers, Jelle On Thu, 27 Mar 2014 17:00:18 +0800, <inkscape-devel-request(a)lists.sourceforge.net> wrote: > Send Inkscape-devel mailing list submissions to > inkscape-devel(a)lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > or, via email, send a message with subject or body 'help' to > inkscape-devel-request(a)lists.sourceforge.net > > You can reach the person managing the list at > inkscape-devel-owner(a)lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Inkscape-devel digest..." > > > Today's Topics: > > 1. Re: [RFC] Proposal for handling fundraisers and funded > development (Bryce Harrington) > 2. Re: [RFC] Proposal for handling fundraisers and funded > development (Jabiertxo Arraiza Cenoz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Mar 2014 19:33:17 -0700 > From: Bryce Harrington <bryce@...961...> > Subject: Re: [Inkscape-devel] [RFC] Proposal for handling fundraisers > and funded development > To: inkscape-devel(a)lists.sourceforge.net > Message-ID: <20140327023317.GA9505@...961...> > Content-Type: text/plain; charset=us-ascii > > Any comments? > > Even just '+1 looks good to me' would be helpful to know. > > Bryce > > On Fri, Mar 21, 2014 at 08:57:00PM -0700, Bryce Harrington wrote: >> Hi all, >> >> The Inkscape board and SFC are interested in facilitating Inkscape >> progress by gathering donations for funding targeted development work. >> >> Below is a draft of a plan for how we could do this. I've run this by >> the lawyers a couple times now, and informally presented it to the board >> for comment, but before we get any further, I'd like to open it up for >> public scrutiny. Once feedback has been incorporated, the next step >> will be to have our board officially vote on it, and put it into >> practice. >> >> I've tried to model this as akin to a Summer of Code, except the >> projects are funded by our community through official fundraisers, and >> the work taken on by Inkscape developers rather than students. I think >> this could be very important to moving our project forward in a big way. >> >> Please take a few moments to review this plan and share with me your >> questions or ideas on how it could be made better. >> >> Thank you, >> Bryce >> >> >> ------------------------------------------------------------------------ >> >> Inkscape Funded Development Model >> --------------------------------- >> >> 1. Fundraising >> =============== >> Using the model we'll describe below, anyone may start an official >> fundraiser for Inkscape development. We leave it to your imagination >> how to structure and run your campaign, so long as a few requirements >> are met. >> >> First, the person who organizes and supervises a fundraising campaign is >> termed a Fundraising Coordinator. We may have multiple coordinators if >> we have multiple campaigns, but only one coordinator per fundraiser. >> They have three duties: >> >> a) Administration of the fundraiser >> b) Allocate raised funds to projects >> c) (Optionally) Be involved in final signoff of completed projects >> >> The first duty is left to the Fundraising Coordinator's discretion. >> >> The second duty should be straightforward. When the fundraiser is >> completed, all funds must be allocated to one or more projects in the >> official Jobs List. No guarantee is made that any given project will be >> undertaken if there is insufficient developer interest, but future >> fundraisers can up the funds allocated to it to stimulate interest. ** Wouldn't it be better to have some tool or method for this? Not only to prevent inconsistencies, but also to improve on the methods themselves? Granted,.. currently there probably is none, but I think it would be better to decide on some mandatory tool for project management. >> >> We expect some campaigns will wish to target one or more specific >> projects, and announce this upfront to stimulate donations. This is >> fine to do, but keep in mind that projects can change (or get >> implemented) while the campaign is under way. So instead of naming >> specific projects, it may be better to describe the types of projects >> the campaign is aiming to fund, and make the specific decision(s) when >> the fundraiser is over. ** If I understand this correctly, the excess funds raised for the finished project can be diverted to other projects at the choice of the fundraiser coordinator? >> >> For ongoing fundraisers, the coordinator responsible for setting it up >> can specify the distribution programmatically (e.g. "distribute evenly >> to the four oldest projects in the list as of the end of the campaign", >> or "10% to each of the ten projects with the highest funding from past >> campaigns", or "allocated evenly across all documentation projects >> registered as of the start of this campaign". The coordinator will >> remain responsible for administrative duties for the length of the >> fundraiser; if they choose to step down, the fundraiser is terminated >> (but another coordinator can start up an equivalent to replace it, under >> their own funding distribution preferences). ** If one fundraiser fails, another person can pick up the job where it left off or has to start all over again? I would suggest the latter to prevent capital being inert and just have raised capital be distributed to other projects if the set bar fails. Or do we do a refund? Maybe have 70% of the funding guaranteed towards the project it is for and 30% to cover the cost of refunds if fail and the rest to the greater goal? >> >> The third duty - signing off on completion of the project - is described >> in more detail below. The Fundraising Coordinator *can't* do this if >> they personally contribute most of the funding, because it'd run us >> afoul of IRS rules. ** Ehm,.. that doesn't sound like too much of a challenge. Bob tells Tom it's finished, Tom signs off. >> >> >> 2. Proposing New Projects >> ========================== >> We maintain a listing of proposed projects. Anything can be proposed, >> including feature development, bug triaging, documentation, >> administration, etc. It must have a defined deliverable and acceptance >> criteria identified, and a time limit for how long the work should take. >> (See appendix for an example set of Acceptance Criteria.) Initially >> these are all made available for volunteers to do freely. When GSoC >> rolls around we use them as suggested projects for students to >> undertake. ** This should be created in a nice project management format with Ganttcharts and all I think. It will make clear how much work is expected to be done and how many people could be involved. Would be some work initially, but will make lots of things clear at the end of the project and it can be easily measured and budgeted. It will also allow for specialist to take part in multiple projects for parts of it and be rewarded accordingly. >> >> Any project that remains on the list unfinished for 6 months becomes >> eligible for funding the work. (This is so that any proposed projects >> that are fun or easy get done by volunteers, and money can be focused on >> harder unsexy work, and to make abuse harder.) We'll call these >> eligible projects 'jobs'. >> ** Wouldn't it be easier to increase funding for higher priority projects? If we combine that with the idea to use part of the funding for fun and sexy project for the tough and tedious, eventually the T&T jobs will be so valuable to fix that it's worth all the hardship and insanity. >> >> 3. Fundable Jobs List >> ====================== >> The money from these fundraisers goes to the Inkscape Foundation account >> administered by the Software Freedom Conservancy, who takes a small >> percentage of each donation. Conservancy is a US 501(c)(3) public >> charity, and all donations are tax deductible in the United States as >> allowed by law. >> >> We maintain a list of allocations-to-jobs so we can keep track of what >> money "belongs" to which job, so the correct amount is paid when the job >> is done. This amount is displayed on the web for developers to browse >> when selecting a job to do. >> >> Anyone in the Inkscape AUTHORS file is eligible to apply for a job. >> The applicant must submit a Job Proposal, which will identify the >> applicant's qualifications for doing the job, and outline how they >> intend to do the implementation. ** Again, if the project is defined by expected tasks it may be useful to have different people work on the same project and have them share the loot. It will be common that parts will be begun by one person and finished by another. >> >> The Inkscape Board will delegate one of its members to review and vet >> applicants to help ensure the best candidates are selected for each job. >> For larger, longer, or more complicated jobs the vetting may take some >> time, but for moderate sized jobs the intent is for a decision to be >> made within a few days. The Inkscape Board may elect to mark some jobs >> (such as smaller ones) as Pre-Approved; once the applicant files an >> application they may begin the job immediately, no vetting required. >> No one may assign themselves more than one Pre-Approved job at a time, >> and the Board reserves the right to subsequently review the application >> and disapprove it in case of problems. ** Sound plan as there are plenty of small projects. Should the board be excluded from these projects I wonder? I actually think this shouldn't be the case as I for one would love them to earn some income for all the work they put into the projects, but there is some danger of having an interest here. Maybe some form of audit would be in place by an independent supervisor. >> >> When an applicant is assigned the job, the clock starts ticking. The >> applicant must post at least one progress report each month (e.g. to a >> blog or to the Inkscape wiki). During the time limit, so long as the >> monthly reports are being clearly posted, no one else can apply to do >> the same job. If two months pass without a report, or when the 6 months >> time runs out, and the job is not completed, the assignee doesn't >> receive the funds and can't attempt the same job again for 6 months. >> The job is considered completed when the identified deliverables are >> delivered according to the specified criteria. ** If we are working with deadlines and milestones it will be easier to track progress and find out when things go awry. >> >> >> 4. Completion Criteria >> ======================= >> The Reviewer makes the decision as to whether the job has been >> adequately completed, using the originally specified criteria. >> >> By default, the Fundraising Coordinator is the Reviewer; if the project >> was funded from multiple sources, the one that allocated the largest >> amount of funding (or their chosen delegate) is the Reviewer. This >> person must formally accept the Reviewer role by email within 1 week. >> For any reason, they may opt to decline the Reviewer role. If they are >> unresponsive or opt to decline the role, it passes to the next >> Fundraising Coordinator. If no Fundraising Coordinators take or >> delegate the role, then the Inkscape Board will delegate a Reviewer. >> >> However the Reviewer is decided, he or she must be a different person >> than the original Project Proposer, and neither the Reviewer nor the >> Reviewer's employer may contribute more than 50% of the total funds for >> the given project. We want to avoid a situation where a person or their >> employer has an independent business interest in seeing the job >> completed, and is over-involved in the management of the work. >> >> If someone other than the assigned Developer performs the work, to the >> satisfaction of the Reviewer, then the assigned Developer will receive >> 70% of the funds. The remaining 30% are returned to the Inkscape >> general fund. ** This is the main reason to work with milestones. The assigned dev should be getting a percentage based on the milestones defined and reached. Those can be weighted rather than just a time percenatge as most of the hard work will be done first (like finding out how to do something), though I would like to have the bug hunting and completion task be weighted quite heavily as well as that is the more tedious and time consuming job. Maybe it should be no more than 50% for the assigned dev if he reaches the task up till the bug hunting phase milestone and it gets completed by a more proficient dev in the end phase, with 30% going to the person who finishes the project and 20% going to the general Fund. >> >> >> 5. Termination and Modification >> ================================ >> The original proposer of the Project or Job may withdraw it or modify >> its definition at any time, so long as someone is not signed up for it. >> If the Project is withdrawn, all funds allocated to it return to the >> general Inkscape fund. >> >> Unassigned Jobs expire 24 months after their initial project proposal. >> This is intended to clear out deadwood projects. >> >> Any funds allocated to that job are moved to Inkscape's general fund. ** Hear, hear.. >> >> >> 6. Process Exceptions >> ====================== >> Historically, all development work funded by the Inkscape Project >> required authorization by the Inkscape Board of Directors; this funding >> model is to establish a structure for development funding that does not >> require Board involvement. However, the Board retains the ability to >> authorize exceptions for anything outside the bounds of this policy, to >> be handled on a case-by-case basis, with decisions made by a majority >> vote. >> >> In particular, the Board may select by vote certain projects to be >> immediately fundable, without needing to wait the normal 6 month period. >> They may also withdraw any project or job at any time, by majority vote. >> >> The Board may also make changes to this policy via a normal majority >> vote. ** It sure makes sense not to have to wait 6 months to get something on the rails. >> >> >> 7. Conflict Resolution >> ======================= >> If there are any problems or disagreements once a project has been >> assigned to a Developer, a Meeting can be called by any stakeholder >> (Project Proposer, Developer, Fundraising Campaigns, Reviewer, or >> Inkscape Board Member). For proper quorum, the Meeting must be attended >> by the Developer, the Project Proposer, the Reviewer, at least one >> Fundraising Coordinator, and one Neutral Developer (whom can be anyone >> in the Inkscape AUTHORS file selected by the Developer). Any unanimous >> decision reached in this Meeting is binding on all parties. ** Surely someone is bound to disagree. This can end up escalating very easily. >> >> Any conflict that can't be resolved via a Meeting may then be escalated >> to the Inkscape Board of Directors, who will be the ultimate arbiter. >> >> Conflicts of interest, including conflicts with the board, are governed >> by the Software Freedom Conservancy's org-wide conflict of interest >> policy. >> >> >> >> Appendix: Example Delivery and Acceptance Criteria >> =================================================== >> # This is a sample set of delivery and acceptance criteria; each project >> # may use, alter, or replace any of these conditions as appropriate. >> >> a. Test cases are provided to add coverage for all newly added >> functionality. >> >> b. Documentation patches provided for describing all newly added >> functionality. >> >> c. Updates provided for release notes, NEWS, bug reports, etc. >> >> d. All patch(es) have landed in the official upstream repository. >> Either >> in the mainline tree, or in an officially designated branch as per >> upstream policy. >> >> e. Code builds and runs on the major platforms supported by the >> project. >> >> f. Code passes the upstream project's designated style/lint checking >> tools. >> >> g. User-visible strings are translatable as per project policy. >> >> h. Unit and regression test suites pass with no new test failures. >> >> At project completion, once the above criteria is met, 90% of the >> payable funds are delivered. 10% is held in reserve for bug fix >> followup: One month after completion, a list of up to 10 identified >> bugs can be specified by the Reviewer to be fixed; if all 10 are fixed >> within a month, the remaining 10% of the funding is released to the >> developer. If no bugs exist, or none are specified before 6 weeks >> after completion, then the developer is paid the 10% directly. ** I would suggest a higher percentage for bug fixes as they're the tougher part of the programming. I would say a 30% for the last few lines of code and all the headaches. It will improve the whole code base if the bugs get caught and everything works to satisfaction. I would certainly add some reward for good annotation of code as well. >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > >

2 1