Changes between Version 6 and Version 7 of SeaChange/DevelopmentProcess
- Timestamp:
- Aug 4, 2020, 9:09:26 AM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SeaChange/DevelopmentProcess
v6 v7 23 23 Comment: Just look at the history of #2456. People cared, wrote patches, discussed the issue. But in the end nothing changed despite the fact that trac doesnt adhere to its design principles in that area (Users not managed via pluggable !Components/Relations) The ticket is '''9 years old'''. There are few comments from team members and virtually no information what problems prevent this to move forward. People got frustrated, wrote competing implementations/plugins or gave up and moved on. I think it's worth analyzing what went wrong here. 24 24 }}} 25 a. lowering the barrier to entry [[br]]25 a. Lowering the barrier to entry [[br]] 26 26 We could achieve this by providing better docs, API docs, 27 27 cleaner and simpler code (ticket:10125#comment:15 has some good hints about this) … … 32 32 33 33 A practical course of a computer science student could be to analyze the sources and create an UML model and some UML diagrams of the whole project. This can highly increase the chance that people realize the architecture and are able to extend it with features like e.g. user management. There are some good community versions of UML tools around for free. - falkb 34 b. motivating people to jump over the barrier34 b. Motivating people to jump over the barrier 35 35 - the great new feature 36 36 - functionality that really makes Trac stand out of the competition 37 37 - monetary remuneration 38 38 - donation mechanism 39 a. Some ideas which may be completely off the mark ...40 - Use more standard libraries. Templating has moved to Genshi, but maybe SQLAlchemy for DB backend?39 a. Some ideas which may be completely off the mark: 40 - Use more standard libraries. Templating has moved to Jinja, but maybe SQLAlchemy for DB backend, such as in [th:SqlAlchemyQueryMacro]? 41 41 - Highlight issues that should be easy for new people to fix: see [query:?status=!closed&keywords=~bitesized] 42 42 - Google summer of code mentoring (requires time though) … … 57 57 === 4. Zero chance of a plugin getting into the core 58 58 59 WebAdmin was integrated. There was some attempt to do the same for60 [TH:AccountManagerPlugin], see also [../WhatUsersWant], but see also point 3: Frequently requested features do not get implemented.59 There was some attempt to integrate 60 [TH:AccountManagerPlugin], see also [../WhatUsersWant], but see also point 2: Frequently requested features do not get implemented. 61 61 - see again ticket:10125#comment:15: getting some parts of the TH:XmlRpcPlugin into core? 62 62 Note that some plugins will never be integrated or even bundled, due to 63 licensing issues (TracMercurial and [TH:GitPlugin]).63 licensing issues, such as TracMercurial and [TH:GitPlugin]. 64 64 [[br]] 65 65 Can someone explain the licensing issues here? I used to be a Trac user, and for me, the main reason I don't think of using it now is that my default option is Github. And I wouldn't think of using a SCM that wasn't distributed. For Trac to remain relevant to me, it needs to support Git or Mercurial as natively as it supports SVN. (Ie. not need me to install and manage a plugin). … … 78 78 === 6. Many Trac tickets have gone stale and they could probably be closed 79 79 80 The currently [[TicketQuery(status=!closed,format=count)]] active tickets, often old and with inflated severity, give a false impression of the state of the project. S ee for instance the history of scary #11174 'blocker', an InstallationIssue that should probably be closed as invalid. Some very old tickets relevant to points 2 and 5 above could be closed as 'wontfix', perhaps with a note suggesting interested parties could write a patch and reopen the ticket if it is still relevant. Many others could be set to low priority and moved to the 'unscheduled' milestone to help reduce the clutter.80 The currently [[TicketQuery(status=!closed,format=count)]] active tickets, often old and with inflated severity, give a false impression of the state of the project. Some very old tickets relevant to points 2 and 5 above could be closed as 'wontfix', perhaps with a note suggesting interested parties could write a patch and reopen the ticket if it is still relevant. Many others could be set to low priority and moved to the 'unscheduled' milestone to help reduce the clutter. Occasional ticket triaging is already underway,.