More FAQs: Q: What do I do about my project for the next 5 weeks if I did not submit a proposal? A: A proposal is for merging features into the master branch, not for working on features. Features should be worked on at any time regardless of proposals, but they are not merged to the master branch and shipped in releases until a proposal for the project has been accepted.
Q: So I can work on my tasks without a proposal? A: Yes, though it should be noted that reviews of the eventual proposal may require a rewrite of the implementation in order to comply with those reviews and have the feature merged. For this reason it is highly advised to either submit the proposal prior to beginning work or to expect that the existing implementation be used as an example that can be refined before being merged. On Mon, Aug 20, 2018 at 8:15 AM Mike Blumenkrantz < [email protected]> wrote: > Hello, > > We've just completed our first round of voting ( > https://phab.enlightenment.org/T7283). The process was a success overall, > and we now have a clear idea of the initial major work items for this > release. With this in mind, some very small changes have been made to the > proposal workflow on phabricator to improve usability and visibility of > proposals: > > * A 'work proposal' tag has been created. If you want to create a proposal > task, tag it with 'work proposal' and 'efl', and it will show up in the > pending proposals sidebar query. > > * Accepted proposals have been tagged with 'active work proposal' and a > sidebar query now exists for these items. > > > Some FAQs: > > Q: I didn't write a proposal for work that I am planning to do, what > happens now? > A: Create a 'work proposal' ticket as described above. 5 weeks from now, a > second voting session will occur, and any proposals which are not rejected > will become features of the 1.22 release. > > Q: What is a proposal? > A: Documentation is being written about this ( > https://phab.enlightenment.org/T7329). A proposal should include a > description of the work which you are planning to do. If the work is > complex, or the reason for it is non-obvious, explanations should be > provided to justify the work. > > Q: Why proposals? > A: Previously, EFL releases were like a giant pile of unrelated and > uncoordinated work. There was no oversight and nobody knew what anyone else > was doing. This methodology provides solutions to these issues and allows > for a framework within which contributors can work cooperatively on > features for each release. > > Q: When do I need a proposal? > A: If you are planning to do work which is large or requires a lot of > change, you should create a proposal. This may include things like major > refactoring projects, adding features affecting multiple components, adding > a feature which fundamentally changes how EFL works/runs/builds, or any > other item which may be considered controversial. > > Q: When do I not need a proposal? > A: If you are adding a trivial feature (e.g., a get method for a property) > or fixing bugs, you probably do not need a proposal. If in doubt, create > one anyway in order to avoid conflict. > > Q: What happens to already-submitted patches which implement features? > A: Patches implementing features which were submitted on phabricator > prior to the 1.21 release will not require proposals and can be > reviewed/accepted normally. This is a one-time acceptance to avoid creating > more work for people who had completed projects prior to the current > development cycle. > > > If anyone has any other questions, let's talk about them so that we can > avoid any confusion. > > Regards, > Mike > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
